Am Dienstag, 14. Oktober 2003 21:31 schrieb G. Del Merritt:
> I've read Matthew Dharm's info/intro on USB Mass Storage:
> 
>     http://www2.one-eyed-alien.net/~mdharm/linux-usb/
> 
> I'm looking for a similar document that can help me answer more generic 
> USB-and-Linux questions, like these:
> 
> - How much specific knowledge does the kernel need about a device?  From 
> looking at kernel changelogs, I see a lot of "add support for device blah"; 
> it seems a waste of time to mod the kernel for each new device.

It is and wouldn't be needed if vendors built devices following the class
specifications and not vendor specific devices.
Although to be fair, some classes are simply lacking.

> - How can user-mode USB apps acquire reasonable access to a specific device 
> without compromising other USB devices also connected to the 
> system/hub?  Is this purely a function of hotplugging and appropriate 
> agents, or does the kernel itself get in to the picture?

The hotplug script shall set the permissions. As usbfs is virtual, there is
absolutely no problem with that.
The granularity of access is determined by usbfs of course.
 
> - Is libusb the only API extant for user-mode applications?  If not, what 
> else is there, and what are some of the trade-offs for using libusb vs. 
> other APIs?

There's a java binding.

> - Is there USB support outside of the kernel?  http://www.linux-usb.org/ 
> implies to me that there are other alternatives, based on a heading there, 
> "Kernel USB stack (aka Linus' Alternative USB stack)"

No longer.

        HTH
                Oliver



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to