Johannes Erdfelt wrote:
Backward compatibility could exist simply by keeping usbfs1 around for a
little while, but keeping it deprecated.
I'd rather start from scratch to avoid some of the mistakes that usbfs1
made.
Agree 100%.
I don't care much about file-per-endpoint and I suspect most other
people wouldn't care much either. It doesn't buy us much.
AIO is definately something I would like to see.
AIO without file-per-endpoint? Possible, I suppose,
with a library layer to demultiplex stuff ... wouldn't
it need to take over the per-request private data field?
But without file-per-endpoint, read() and write() won't
work ... so these file descriptors can't just be handed
around to other processes that know nothing about usbfs.
I agree. While libusb works with C and C++, other programming languages
should be able to use usbfs2 as well.
And that works a lot more easily with file-per-endpoint, since
those language runtimes probably already include open/close
and read/write. The alternative is new glue libraries, likely
in C instead of native to that language, to demux things.
If sysfs works well, I don't see any requirement for usbfs2 to duplicate
that feature.
Especially since sysfs works for all devices.
Right. Some features belong in sysfs, others don't.
* How should this relate to "udev"? One implementation
strategy would make "usbfs2" endpoint files be regular
character devices. There are other strategies too,
including not coupling them at all.
Perhaps a sockets interface would be more appropriate?
Certainly there are ideas to steal from the network stacks.
How do they deal with iso transfers, do you know?
Device nodes work well for a generic API like block or character
devices, but it gets into problems with USB.
What are the problems you're thinking about? Even control
transfers can be done with just write/read.
Anyway, that's a bunch of random thoughts and questions in the
direction of "usbfs2". I hope they can help seed discussions!
To be honest usbfs1 hasn't limited the functionality in libusb too much.
I would just like to see cleaner interfaces in some areas. Specifically
asynchronous transfers and device connect/removal.
Could you elaborate a bit about the connect/remove issues?
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
