umass: should the device specific information be moved from C code to the text file?

[Bernd Walter]

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.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de