>>I really like the "event for each interface" change, though I'd
>>like it a bit better if we could tell this 2.5+ behavior apart
>>from earlier ones -- so hotplug agents can act accordingly.
> 
> 
> What needs to be different?

As I suggested, a KFS-only environment variable would be fine.


>>    Hotplug agents will need to access KFS data *and* talk to the
>>    device (and its drivers) using the DEVICE= path.  Plus, if this
>>    is present we know we don't need to ask 'usbmodules' to scan
>>    other interfaces for us.  (That often triggers other problems.)
> 
> 
> Wait, why does anyone need to use the usbfs path (what is specified by
> DEVICE= in the usb code)?  All of the info that usbmodules used to get
> is now present in DEV_PATH, right?  If not, let me know.

I think device speed is still unavailable through KFS, and I suspect
the extra audio descriptor bytes aren't exposed, but other than that
the read-only access modes are about equivalent.

But USBFS lets you interact with the device, and every user mode driver
(or configuration tool) relies on that.  Many of them hook up through
hotplug.  KFS doesn't; which is why the agents will continue to need
the USBFS path.


There's also the "coldplug" situation.  KFS _could_ remember which
devices didn't have hotplug events issued (a device state flag) and
rescan its tree to issue them, after the kernel's come up enough that
/sbin/hotplug can safely be called.  Only solving that issue lets us
completely get rid of "usbmodules".


> Also, any reason to keep the DEVFS variable?  It's wrongly named, and
> doesn't look like anyone uses it.

Not any longer.  But update the docs (on the hotplug website).

- Dave






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to