[Openswan Users] FW: CRADA software

[Keun Lee]

> I've glanced over your code and I'd like to know where I can find the
> list of possible fcts that access the USB. For instance your drvr code
> uses "usb_bulk_read" & "usb_bulk_write". Is there  a "usb_interrupt_read",
> etc. ?
>
The generic USB kernel driver interface of libusb functions are shown in
the usb.h file (attachment). Yes, there are usb_interrupt_read()
and usb_interrupt_write() functions.

> Also, you have "usb_reset", "usb_detach_kernel_driver_np" &
> "usb_claim_interface" as part of the user code. Why didn't you embed
> those into one of your drvr APIs ?

usb_reset() and usb_claim_interface() are generic kernel interface
functions of libusb.

>
> By "usb_detach_kernel_driver_np" & "usb_claim_interface", it looks
> like you've disabled whatever std usb drvr might already be in the
> kernel. Or does this mean something else ?
> Does it mean, a USB memory stick or a USB keyboard device will no
> longer work while your drvr is active ?
> Does "usb_release_interface" restore the kernel USB drvr ?

If I used usb_detach_kernel_driver_np() function on a device like
USB memory stick, it will stop working the usual way afterwards.
I will have to explicitly reconnect the device to the kernel
file system driver, perhaps using a USBDEVFS_CONNECT ioctl call.
Same goes with human interface devices like keyboard or mouse.
The usb_release_interface() function does not reconnect.
For a "QKD" device, this shouldn't be an issue since there is no
useful kernel driver for the device.

>
> Why did you do a user interface drvr vs a loadable kernel module ?

Ideally we would implement a "QKD class device" driver in the kernel.
However, there is no consensus on what and how this class of device
works yet. Therefore, it would be some time before we can define
a stable kernel driver function for it. I think the application level
driver is a prudent solution since it allows safe and rapid changes
to support the QKD application by mortal application software developers.

By the way, the endpoint numbers 2 and 6 are hardcoded in the main
program. If you need to test endpoints 4 and 8, you need to change
the numbers in lines 82 and 91 of UsbTest.c.
You can also get more verbose information by changing the debug
level to a non-zero value in line 31 (usb_set_debug()).

Hope this answers your questions.

Keun

>
> Thanks,
> Alan
> ---------------------------------------------------------------
>
> Keun Lee wrote:
>
>>Good news!
>>Let me know if you need any help from here.
>>
>>Keun
>>
>>
>>
>>>Your updated files seem to install & work okay.
>>>When I execute it, I get the "found the device" msg followed
>>>by "Select: r[1..9], w, q ---".
>>>
>>>I'll try & rewrite the FPGA code to ignore the corrupted clk
>>>& see if I can  accomplish any rds & wrts.
>>>
>>>I'll also look into the 2.6.20 mach problem.
>>>
>>>Thanks,
>>>Alan
>>>-----------------------------------------------------------------
>>>
>>>Keun Lee wrote:
>>>
>>>
>>>
>>>>>I've got a mtg & will rtn about 6:00.
>>>>>
>>>>>If you're gone by then, we can pick this up on Mon.
>>>>>
>>>>>Alan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The new tar file is attached. We had one more command line
>>>>argument in earlier verion and we forgot to remove it.
>>>>So, it was using the default vendor/product IDs.
>>>>My apologies. The software will print the device and vendor
>>>>IDs it is looking for.
>>>>
>>>>Your box does have UDB kernel drivers.
>>>>
>>>>
>>>>
>>>>
>>>>>>ehci_hcd               33997  0
>>>>>>ohci_hcd               23493  0
>>>>>>uhci_hcd               26705  0
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>It simply does not
>>>>have the USB API library (libusb.a) for the user applications.
>>>>>From your uname output, I can't figure out what distribution
>>>>it is based on - redhat, debian, etc. If you could ask the
>>>> administrator
>>>>about missing usb.h and libusb.a, you may get useful info.
>>>>
>>>>I will be leaving at 5:30. So, let's pick it up Monday.
>>>>
>>>>Cheers,
>>>>
>>>>Keun
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb.h
Type: text/x-chdr
Size: 8320 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20070709/43fe3e0e/attachment.bin