Am Dienstag, 22. Januar 2008 19:36:45 schrieben Sie: > > I guess so, because what I'm trying to do is merely just to expose some > > of the device's (interrupt) endpoints as separate character device files > > under /dev. The "real" communication is thus moved to a user space app / > > lib which handles the control of the device with simple read() and > > write() calls to the various characters device files. Works fine so for > > one endpoint, but as said, due to the limitation of struct > > usb_interface (being limited to just one minor per USB interface), I > > could not simply add another usb_register_dev() call to create further > > character devices for the other endpoints of same USB interface. > > Then why not just use usbfs/libusb directly? That sounds like it would > work for you, and no kernel driver is needed at all.
Because I don't want to. ;) No, there are couple reasons for doing it as a kernel module. For example I planned to use it in an slim embedded device which only runs one single app directly from the kernel's init, with everything statically compiled in and the kernel module will be small anyway, so it avoids some intricacies. I used the misc interface now. I also had a look at the usbfs2 code, which is pretty much what I feared I have to code, but the downside would be wasting of a major just for that single device driver, so the misc interface is just perfect. > > If I'd provide a patch, replacing the scalar member of struct > > usb_interface by a list of minors instead, would that a have a chance to > > be applied to the upstream kernel? Or is there probably a good reason for > > keeping it a scalar? > > Yes, we need to keep it on a per-interface level because that is what > drivers bind to, not individual endpoints, or endpoint pairs. I don't quite get why this couldn't be accomplished with a list as well, but at least I haven't wasted time for a patch that would be rejected anyway. :) Thanks for all the tips, helped me a lot! CU Christian - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
