Re: umass: should the device specific information be moved from C code to the text file?
Peter Jeremy wrote: This sounds like a nice idea - it's also a nuisance having to recompile the kernel just to support a weird new USB device you've acquired. You can probably keep USB support as a module if you need to recompile it often :) On the original topic: please don't do that. Recent ultra-modern Linux systems have started offloading such critical kernel functionalities to the userland, making it almost impossible to deal with when things go bad (e.g. in single user mode). See also trouble ZFS has in single user mode because it relies on files in the file system and a userland rc.d script (hostid). signature.asc Description: OpenPGP digital signature
Re: umass: should the device specific information be moved from C code to the text file?
On Fri, Feb 29, 2008 at 12:44:44PM +0100, Ivan Voras wrote: Peter Jeremy wrote: This sounds like a nice idea - it's also a nuisance having to recompile the kernel just to support a weird new USB device you've acquired. You can probably keep USB support as a module if you need to recompile it often :) On the original topic: please don't do that. Recent ultra-modern Linux systems have started offloading such critical kernel functionalities to the userland, making it almost impossible to deal with when things go bad (e.g. in single user mode). See also trouble ZFS has in single user mode because it relies on files in the file system and a userland rc.d script (hostid). It doesn't work anyway, since umass doesn't attach to device/vendor-ID. umass(4) is a interface class driver and attaches to each device containg a umass class interface independend of vendor/device-ID. There may be some exeptions for devices, which fail to supply the correct decriptor tables however, but the majority of supported devices are unknown to the driver. If you need ugen and umass, then fix ugen to attach even if another driver(s) already controls the device or some interfaces. This may be tricky, since ugen allows things that may break the expectations of other drivers, but we should have a solution for this problem anyway. Maybe we can live with this risk, while ugen is enhanced to do dafety catches - we have much more dangerous risks with USB right now, such as detaching mounted umass media. Not sure if HPS stack already handles the ugen vs. other driver problematic. AFAIK under Linux the generic userland interface allows claiming devices/interfaces from userland. It could be good idea for us as well and it would be good for libusb support as well. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
umass: should the device specific information be moved from C code to the text file?
Currently all devices supported by umass driver are listed in * sys/dev/usb/usbdevs - which has vendor table (vendor-id/name) - and product table (ref-to-vendor-id/product-id/name) and * sys/dev/usb/umass.c - which has some per-device flags. The problem with this way is that some people might want to disable umass for particular devices. For example some people prefer to use gphoto2 with usb-cameras and gphoto2 needs the device to be ugen. I suggest device specific information should be moved from sys/dev/usb/usbdevs and sys/dev/usb/umass.c to some text file (ex. /etc/umass-devices) which would be read by umass driver when it's loaded. This way users will be able to easily remove/add entries without the need to recompile the module. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass: should the device specific information be moved from C code to the text file?
On Thu, Feb 28, 2008 at 02:14:58PM -0800, Yuri wrote: Currently all devices supported by umass driver are listed in * sys/dev/usb/usbdevs - which has vendor table (vendor-id/name) - and product table (ref-to-vendor-id/product-id/name) and * sys/dev/usb/umass.c - which has some per-device flags. And (for completeness): * src/sys/cam/scsi/scsi_da.c - contains device quirks. I suggest device specific information should be moved from sys/dev/usb/usbdevs and sys/dev/usb/umass.c to some text file (ex. /etc/umass-devices) which would be read by umass driver when it's loaded. This sounds like a nice idea - it's also a nuisance having to recompile the kernel just to support a weird new USB device you've acquired. Unfortunately, accessing the filesystem from within the kernel is not that easy. One problem with your suggestion of accessing the file when umass is loaded is that if imass is compiled into the kernel, it will go through the probe/attach phase before there's a root filesystem - which makes reading files somewhat difficult. What might be more useful is for the USB system to interrogate a file (or similar) when a USB device is inserted to allow the user to control which usb driver gains control of the device - as well as the camera example you use, this would also be useful with multi-function printer/scanner/... devices. Again, accessing a file is not trivial but may be practical. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgputmyPBcgKI.pgp Description: PGP signature
