/sbin/hotplug invocation for USB devices in 2.5.40

/sbin/hotplug invocation for USB devices in 2.5.40

[Greg KH]

As almost no one noticed, I changed the environment variables that
/sbin/hotplug is called with in 2.5.40 :)

This is what has changed from the previously documented info at
http://linux-hotplug.sourceforge.net/?selected=usb

For USB devices, /sbin/hotplug is called for the main device, and every
interface.  For the interfaces, the info in the above link is still set.
Previously, /sbin/hotplug only got called once, and we only sent the
first interface's information.  We should now be able to handle compound
devices much easier.

For the USB device (not the interface), the only environment variable
is:
	DEVICE = <place in driverfs tree for the device>
For the interface, it's the same as it used to be.

This variable is also set for every other /sbin/hotplug call that
happens (which is now for every type of device in the kernel, not just
the types we used to have.)

Now I know this overloads the existing DEVICE usage for USB devices, but
I think we can determine what do properly (basically just test for
DEVFS, and if it's not set, then we are looking at the driverfs entry
for the device.)

I also created a lot of individual driverfs files for the USB device,
basically everything that used to be specified by a environment variable
in the call to /sbin/hotplug, is now a value in a file.  So ideally, we
can get rid of those other variables for the USB call, and just rely on
the info present in driverfs.

I'll be doing the same thing for PCI devices to try to get rid of their
extra variables.

Does this all sound ok?  Problematic?  Even make any sense?

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[David Brownell]

Greg KH wrote:
> As almost no one noticed, I changed the environment variables that
> /sbin/hotplug is called with in 2.5.40 :)

I look at it just a bit differently ... where previously it only
issued calls for the first interface (typically that's all there is),
now it issues calls for every interface, _plus_ a call for a new kind
of thing never before seen through hotplug, a "usb device".

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.

Its that new type of hotplug event that makes recent kernels trigger
syslog messages about "Bad USB agent invocation".


> Now I know this overloads the existing DEVICE usage for USB devices, but
> I think we can determine what do properly (basically just test for
> DEVFS, and if it's not set, then we are looking at the driverfs entry
> for the device.)

I'd rather see these changes:

   - This new parameter to every (!!) hotplug event gets renamed to
     KFS_DEVICE (assuming that's the new driverfs name).

     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.)

   - Don't make hotplug calls for USB devices until we have something
     for them to do.  (Essentially these are a new class of event.)

     The example that comes to mind is policy agents using those
     events to choose a non-default device configuration.  But USB
     needs a bunch of work before such things become practical.

I think both of those would be simple changes to make.  They'd
greatly improve backward compatibility, while letting us do better
things on Linux Next Generation systems.



> I also created a lot of individual driverfs files for the USB device,
> basically everything that used to be specified by a environment variable
> in the call to /sbin/hotplug, is now a value in a file.  So ideally, we
> can get rid of those other variables for the USB call, and just rely on
> the info present in driverfs.

That'd only work if both KFS_DEVICE and DEVICE are simultaneously available.
See above ... :)  I wouldn't de-support the other parameters for quite
a while, though it's certainly good to have such improved flexibility.

By the way, what's the cost of a driverfs attribute on a 'struct device'?
Each USB device now has over a dozen of them.

- Dave





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Patrick Mochel]

> > Now I know this overloads the existing DEVICE usage for USB devices, but
> > I think we can determine what do properly (basically just test for
> > DEVFS, and if it's not set, then we are looking at the driverfs entry
> > for the device.)
> 
> I'd rather see these changes:
> 
>    - This new parameter to every (!!) hotplug event gets renamed to
>      KFS_DEVICE (assuming that's the new driverfs name).

What about DEVPATH, since that's what it is, right?

> By the way, what's the cost of a driverfs attribute on a 'struct device'?
> Each USB device now has over a dozen of them.

32 bytes/attribute + size of the function. But, attributes are reused 
across devices, so the total data cost is 32 x ~16 = 512. 

	-pat



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Oliver Neukum]

> I also created a lot of individual driverfs files for the USB device,
> basically everything that used to be specified by a environment variable
> in the call to /sbin/hotplug, is now a value in a file.  So ideally, we
> can get rid of those other variables for the USB call, and just rely on
> the info present in driverfs.
>
> I'll be doing the same thing for PCI devices to try to get rid of their
> extra variables.
>
> Does this all sound ok?  Problematic?  Even make any sense?

At first glance problematic. Invocation with enviromental variables
is atomic, reading values from driverfs is not.

I'll have a thorough look at the matter.

	Regards
		Oliver



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[David Brownell]

Patrick Mochel wrote:
>>>Now I know this overloads the existing DEVICE usage for USB devices, but
>>>I think we can determine what do properly (basically just test for
>>>DEVFS, and if it's not set, then we are looking at the driverfs entry
>>>for the device.)
>>
>>I'd rather see these changes:
>>
>>   - This new parameter to every (!!) hotplug event gets renamed to
>>     KFS_DEVICE (assuming that's the new driverfs name).
> 
> 
> What about DEVPATH, since that's what it is, right?

Well, it's different from usb_device->devpath ... devpath is just
one component of the KFS path.  One that's repeated because of
that requirement that names assigned by a bus be unique across
the whole system, making it easier to automate that symlinking. :)

It's not the only filesystem path used to access the device.
Would using KFS_DEVICE really be a problem?



>>By the way, what's the cost of a driverfs attribute on a 'struct device'?
>>Each USB device now has over a dozen of them.
> 
> 
> 32 bytes/attribute + size of the function. But, attributes are reused 
> across devices, so the total data cost is 32 x ~16 = 512. 

"Reused" meaning shared attributes like "name" and "power", I guess.

USB devices have at least one interface, and each will have six attributes
(including name+power).  So 32 x ~24 = 768 bytes minimum, on top of other
costs. These start to add up.

- Dave






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Oliver Neukum]

>    - Don't make hotplug calls for USB devices until we have something
>      for them to do.  (Essentially these are a new class of event.)
>
>      The example that comes to mind is policy agents using those
>      events to choose a non-default device configuration.  But USB
>      needs a bunch of work before such things become practical.

And reporting the thing to a desktop enviroment.
The cost is small and the thing is potentially useful.

We discussed such stuff in Cologne and came to the conclusion that
user space wants all information on device<->interface relationship it
can get.

	Regards
		Oliver



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Greg KH]

On Tue, Oct 08, 2002 at 10:02:59AM -0700, David Brownell wrote:
> Greg KH wrote:
> >As almost no one noticed, I changed the environment variables that
> >/sbin/hotplug is called with in 2.5.40 :)
> 
> I look at it just a bit differently ... where previously it only
> issued calls for the first interface (typically that's all there is),
> now it issues calls for every interface, _plus_ a call for a new kind
> of thing never before seen through hotplug, a "usb device".
> 
> 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?

> Its that new type of hotplug event that makes recent kernels trigger
> syslog messages about "Bad USB agent invocation".

Hey, it's not my fault you have good error checking :)

Seriously, we're going to have to upgrade the hotplug scripts for 2.5
anyway, so this problem will go away soon enough.

> >Now I know this overloads the existing DEVICE usage for USB devices, but
> >I think we can determine what do properly (basically just test for
> >DEVFS, and if it's not set, then we are looking at the driverfs entry
> >for the device.)
> 
> I'd rather see these changes:
> 
>   - This new parameter to every (!!) hotplug event gets renamed to
>     KFS_DEVICE (assuming that's the new driverfs name).

I like Pat's suggestion of DEV_PATH.  Does anyone object to this?

>     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.

>   - Don't make hotplug calls for USB devices until we have something
>     for them to do.  (Essentially these are a new class of event.)

Why not?  That lets us load drivers based on vendor and product id.  The
interface specific calls let us load protocol specific drivers, giving
us a semblance of heirachy that a lot of people used to want a few years
ago (and Johannes provided a patch for a long time ago.)

And if the hotplug scripts don't want to do anything with this event,
it's quite easy to ignore :)

>     The example that comes to mind is policy agents using those
>     events to choose a non-default device configuration.  But USB
>     needs a bunch of work before such things become practical.

The USB core needs it?  Or the hotplug scripts?

I'm curious about this, as I'm looking at a device that might need to
have it's second configuration enabled if it's running on Linux, yet the
default config is for when running on Windows.

> >I also created a lot of individual driverfs files for the USB device,
> >basically everything that used to be specified by a environment variable
> >in the call to /sbin/hotplug, is now a value in a file.  So ideally, we
> >can get rid of those other variables for the USB call, and just rely on
> >the info present in driverfs.
> 
> That'd only work if both KFS_DEVICE and DEVICE are simultaneously available.
> See above ... :)  I wouldn't de-support the other parameters for quite
> a while, though it's certainly good to have such improved flexibility.

Well, with a rename to DEV_PATH that should work out fine.

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

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Greg KH]

On Tue, Oct 08, 2002 at 11:14:22AM -0700, David Brownell wrote:
> >
> >What about DEVPATH, since that's what it is, right?
> 
> Well, it's different from usb_device->devpath ... devpath is just
> one component of the KFS path.  One that's repeated because of
> that requirement that names assigned by a bus be unique across
> the whole system, making it easier to automate that symlinking. :)
> 
> It's not the only filesystem path used to access the device.
> Would using KFS_DEVICE really be a problem?

No, but DEVPATH is nicer looking imho :)

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[David Brownell]

>>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
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Greg KH]

On Tue, Oct 08, 2002 at 02:00:57PM -0700, David Brownell wrote:
> 
> I think device speed is still unavailable through KFS,

Good catch, I'll go add that.

> and I suspect the extra audio descriptor bytes aren't exposed, but
> other than that the read-only access modes are about equivalent.

That should go into the audio driver, not the usb core.

> 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.

I want to remove the fact that usbfs is being used by the hotplug
scripts.  I don't care about any userspace drivers or configuration
scripts, they can determine the usbfs location from the driverfs/kfs
device already.

> 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".

No, kfs isn't going to do a "coldplug" store and replay thing.
What is going to happen is /sbin/hotplug will be present early in the
boot due to initramfs, so the proper modules will already be loaded.  If
userspace wants to walk the driverfs/kfs tree when init starts up,
that's up to it.

And yes, I really want to get rid of usbmodules too :)

> >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).

Will do.

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[David Brownell]

>>  - Don't make hotplug calls for USB devices until we have something
>>    for them to do.  (Essentially these are a new class of event.)
> 
> 
> Why not?  That lets us load drivers based on vendor and product id.  The
> interface specific calls let us load protocol specific drivers, giving
> us a semblance of heirachy that a lot of people used to want a few years
> ago (and Johannes provided a patch for a long time ago.)

I didn't know we had any problems loading drivers based on vendor+product ...
sure seems like I've been doing it for a few years now!

Today's MODULE_DEVICE_TABLE, with flags, should be isomorphic to as much
of a hierachy as is really needed.  I seem to recall Johannes saying his
patch didn't do everything MSFT seemed to say needed doing, either.



>>    The example that comes to mind is policy agents using those
>>    events to choose a non-default device configuration.  But USB
>>    needs a bunch of work before such things become practical.
> 
> 
> The USB core needs it?  Or the hotplug scripts?
> 
> I'm curious about this, as I'm looking at a device that might need to
> have it's second configuration enabled if it's running on Linux, yet the
> default config is for when running on Windows.

The usbcore code is pretty confused about changing configurations.
As I recall, it doesn't even bother unbinding drivers from the
first configuration's interfaces when it sets a new config, so
it's just accidental if it works safely (no drivers bound yet,
no urbs in progresss, and so on).

- Dave




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[David Brownell]

Oliver Neukum wrote:
>>   - Don't make hotplug calls for USB devices until we have something
>>     for them to do.  (Essentially these are a new class of event.)
>>
>>     The example that comes to mind is policy agents using those
>>     events to choose a non-default device configuration.  But USB
>>     needs a bunch of work before such things become practical.
> 
> 
> And reporting the thing to a desktop enviroment.

The software I've heard of that does such things today is perfectly
happy with today's interface level notification.


> The cost is small and the thing is potentially useful.

Equivalently:  it's not free, and we don't know what it'd be good for.

That "small and potentially useful" argument is the essence of
feature creep, which is why I don't like it.  I'd far rather
see some examples of improvements it would enable ... but I
don't think there are any, since it'd be just a subset of what
we can already do without such calls.


> We discussed such stuff in Cologne and came to the conclusion that
> user space wants all information on device<->interface relationship it
> can get.

It's sitting there in KFS already, nobody's proposing that it be removed.

- Dave




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Greg KH]

On Tue, Oct 08, 2002 at 02:18:48PM -0700, David Brownell wrote:
> 
> >> - Don't make hotplug calls for USB devices until we have something
> >>   for them to do.  (Essentially these are a new class of event.)
> >
> >
> >Why not?  That lets us load drivers based on vendor and product id.  The
> >interface specific calls let us load protocol specific drivers, giving
> >us a semblance of heirachy that a lot of people used to want a few years
> >ago (and Johannes provided a patch for a long time ago.)
> 
> I didn't know we had any problems loading drivers based on vendor+product 
> ...
> sure seems like I've been doing it for a few years now!

Doh, nevermind, I shouldn't write on an empty stomach...

> Today's MODULE_DEVICE_TABLE, with flags, should be isomorphic to as much
> of a hierachy as is really needed.  I seem to recall Johannes saying his
> patch didn't do everything MSFT seemed to say needed doing, either.

I also remember the MSFT documentation being to complex for what is
really needed :)

Anyway, it was just a suggestion, I need to update diet-hotplug to work
with the new fields and see if I can get away with just using the
driverfs/kfs files.

thanks,

greg k-h



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[David Brownell]

>>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.
> 
> 
> I want to remove the fact that usbfs is being used by the hotplug
> scripts.  

So far as the "load the driver" part of those scripts, I agree it
shouldn't be needed.  But hotplug agents do more than just loading
drivers


 > 	I don't care about any userspace drivers or configuration
> scripts, they can determine the usbfs location from the driverfs/kfs
> device already.

Not the last time I looked they couldn't !!

But even if they could, then the hotplug scripts would want to set
the usbfs DEVICE= parameter before calling setup/config scripts,
which often call userspace drivers.   Intentionally breaking such
third party software is not somehing I'm keen on.


>>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".
> 
> 
> No, kfs isn't going to do a "coldplug" store and replay thing.

I've yet to hear another scheme that would solve the whole
"coldplug" problem, though ... there always seems to be some
case (like the right driver being missing from initramfs) that
is more naturally handled just by deferring the event report.

Not store/replay -- one bit per device, and ftw() code that
could likely be removed after the system's running.


> What is going to happen is /sbin/hotplug will be present early in the
> boot due to initramfs, so the proper modules will already be loaded.  If
> userspace wants to walk the driverfs/kfs tree when init starts up,
> that's up to it.
> 
> And yes, I really want to get rid of usbmodules too :)

I've heard of this initramfs scheme, but it's almost Hallowe'en ...
but maybe this falls under the "scarey costume" exception!  :)

- Dave



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: /sbin/hotplug invocation for USB devices in 2.5.40

[Greg KH]

On Wed, Oct 09, 2002 at 08:15:27AM -0700, David Brownell wrote:
> > 	I don't care about any userspace drivers or configuration
> >scripts, they can determine the usbfs location from the driverfs/kfs
> >device already.
> 
> Not the last time I looked they couldn't !!
> 
> But even if they could, then the hotplug scripts would want to set
> the usbfs DEVICE= parameter before calling setup/config scripts,
> which often call userspace drivers.   Intentionally breaking such
> third party software is not somehing I'm keen on.

Ok, this makes sense.  I've fixed the DEVICE overloading with the last
round of patches I sent off, so we shouldn't have this problem anymore.

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel