2.5.26 hotplug failure

2.5.26 hotplug failure

[Duncan Sands]

I just gave 2.5.26 a whirl.  The first thing I noticed was
that the hotplug system didn't run the script for my usb
modem...

kernel: usb.c: USB disconnect on device 2
kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by any active driver.
/etc/hotplug/usb.agent: ... no modules for USB product 6b9/4061/0

however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only difference
is the change in kernel)...

All the best,

Duncan.

Re: 2.5.26 hotplug failure

[Greg KH]

On Thu, Jul 18, 2002 at 09:50:42AM +0200, Duncan Sands wrote:
> I just gave 2.5.26 a whirl.  The first thing I noticed was
> that the hotplug system didn't run the script for my usb
> modem...
> 
> kernel: usb.c: USB disconnect on device 2
> kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
> kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by any active driver.
> /etc/hotplug/usb.agent: ... no modules for USB product 6b9/4061/0
> 
> however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only difference
> is the change in kernel)...

But that message is from the hotplug agent, right?

What kind of script used to get run, and how was it run (i.e. on network
interface registration, etc.)

thanks,

greg k-h

Re: 2.5.26 hotplug failure

[Duncan Sands]

On Thursday 18 July 2002 20:36, Greg KH wrote:
> On Thu, Jul 18, 2002 at 09:50:42AM +0200, Duncan Sands wrote:
> > I just gave 2.5.26 a whirl.  The first thing I noticed was
> > that the hotplug system didn't run the script for my usb
> > modem...
> >
> > kernel: usb.c: USB disconnect on device 2
> > kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
> > kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by
> > any active driver. /etc/hotplug/usb.agent: ... no modules for USB product
> > 6b9/4061/0
> >
> > however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only
> > difference is the change in kernel)...
>
> But that message is from the hotplug agent, right?

Yup, which normally (using the product id etc) works out that it needs
to run "the script for my usb modem".

> What kind of script used to get run, and how was it run (i.e. on network
> interface registration, etc.)

It was run by the hotplug system - it uploads firmware then launches the
internet connection.  The hotplug script knows to run it by looking up the
vendor/product id in a list.  Doesn't info get passed to the hotplut script via
environment variables?  Maybe they are not getting set up right...

I'm leaving now for one month so I'm afraid it will be a while until I'll
next be able to look at this...

Ciao,

Duncan.

Re: 2.5.26 hotplug failure

[Duncan Sands]

On Thursday 18 July 2002 20:36, Greg KH wrote:
> On Thu, Jul 18, 2002 at 09:50:42AM +0200, Duncan Sands wrote:
> > I just gave 2.5.26 a whirl.  The first thing I noticed was
> > that the hotplug system didn't run the script for my usb
> > modem...
> >
> > kernel: usb.c: USB disconnect on device 2
> > kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
> > kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by
> > any active driver. /etc/hotplug/usb.agent: ... no modules for USB product
> > 6b9/4061/0
> >
> > however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only
> > difference is the change in kernel)...
>
> But that message is from the hotplug agent, right?
>
> What kind of script used to get run, and how was it run (i.e. on network
> interface registration, etc.)
>
> thanks,
>
> greg k-h

OK, I've worked out what was wrong (patch below): /proc/bus/usb was
being unmounted by the hotplug/usb.rc script.  After loading a HCD, usb.rc
executes the following lines:

    if [ -d /proc/bus/usb ]; then
        # If we see there are no busses, we "failed" and
        # can report so even if we're partially nonmodular.
        COUNT=`ls /proc/bus/usb | wc -l`
        if [ $COUNT -le 2 ]; then
            umount /proc/bus/usb
            rmmod usbcore >/dev/null 2>&1
            return 1
        fi

In the 2.4 kernels, /proc/bus/usb contains at least

001  devices  drivers

i.e. at least three entries.  However sometime during
the 2.5 kernel series the drivers file went away.  So
now there are only two entries and usb.rc unmounts
/proc/bus/usb.

A simple fix is to change the test to [ $COUNT -lt 2 ];

Duncan.

--- hotplug/usb.rc.orig	2002-09-15 23:29:14.000000000 +0200
+++ hotplug/usb.rc	2002-09-15 23:29:39.000000000 +0200
@@ -149,7 +149,7 @@
 	# If we see there are no busses, we "failed" and
 	# can report so even if we're partially nonmodular.
 	COUNT=`ls /proc/bus/usb | wc -l`
-	if [ $COUNT -le 2 ]; then
+	if [ $COUNT -lt 2 ]; then
 	    umount /proc/bus/usb
 	    rmmod usbcore >/dev/null 2>&1
 	    return 1

Re: 2.5.26 hotplug failure

[Greg KH]

On Sun, Sep 15, 2002 at 11:53:41PM +0200, Duncan Sands wrote:
> 
> A simple fix is to change the test to [ $COUNT -lt 2 ];

Good catch, yes the drivers file disappeared, and until now, almost no
one noticed it :)

I'll go apply this patch.

Thanks again for finding this.

greg k-h

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 18 Sep 2002 16:52, Greg KH wrote:
> On Sun, Sep 15, 2002 at 11:53:41PM +0200, Duncan Sands wrote:
> > A simple fix is to change the test to [ $COUNT -lt 2 ];
>
> Good catch, yes the drivers file disappeared, and until now, almost no
> one noticed it :)
I assume that /proc/bus/usb/drivers went to driverfs. Everyone likes the new 
guy :)

I'd like the file back. We have a lot of debugging advice that asks people to 
send that particular file to us, and it is very useful. Even if you update 
the few places that you can find, then you will still have a lot of confusion 
(well, if you have 2.4, then send this, and if you have 2.6, send this, and 
if that doesn't exist, and you're on 2.4, mount this filesystem, else mount 
this filesystem). Ugly, and increases the support workload.

A symlink will do, assuming both filesystems are mounted. If we only have 
usbfs, I still want the data.

Please fix this before 2.6.

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9iCgnW6pHgIdAuOMRAgRcAJ9+i0ksw2S4qS8wvA+SD5prjA4IEwCcCulE
APZsrWY1WlNoY42cG8pXUTI=
=GNYM
-----END PGP SIGNATURE-----

Re: 2.5.26 hotplug failure

[Greg KH]

On Wed, Sep 18, 2002 at 05:15:50PM +1000, Brad Hards wrote:
> On Wed, 18 Sep 2002 16:52, Greg KH wrote:
> > On Sun, Sep 15, 2002 at 11:53:41PM +0200, Duncan Sands wrote:
> > > A simple fix is to change the test to [ $COUNT -lt 2 ];
> >
> > Good catch, yes the drivers file disappeared, and until now, almost no
> > one noticed it :)
> I assume that /proc/bus/usb/drivers went to driverfs. Everyone likes the new 
> guy:)

The functionality went there, not the actual file.  The file is obsolete
now :)

> I'd like the file back. We have a lot of debugging advice that asks people to 
> send that particular file to us, and it is very useful. Even if you update 
> the few places that you can find, then you will still have a lot of confusion 
> (well, if you have 2.4, then send this, and if you have 2.6, send this, and 
> if that doesn't exist, and you're on 2.4, mount this filesystem, else mount 
> this filesystem). Ugly, and increases the support workload.
> 
> A symlink will do, assuming both filesystems are mounted. If we only have 
> usbfs, I still want the data.

'ls <wherever_you_mounted_driverfs>/bus/usb/drivers' will now show you
all of the registered USB drivers.  As for what the minor numbers are
for the drivers that happened to use the USB major number, I'm working
on that.

> Please fix this before 2.6.

Sorry, but I'm not going to put the file back.  I understand your
concerns.  We should have some kind of program (lsdev like) that shows
the system information present at that moment in time.  It will be able
to provide what the /proc/bus/usb/drivers file showed in the past.

thanks,

greg k-h

Re: 2.5.26 hotplug failure

[Daniel Phillips]

On Wednesday 18 September 2002 18:55, Greg KH wrote:
> Sorry, but I'm not going to put the file back.  I understand your
> concerns.  We should have some kind of program (lsdev like) that shows
> the system information present at that moment in time.  It will be able
> to provide what the /proc/bus/usb/drivers file showed in the past.

How about calling it /proc/bus/usb/drivers?

-- 
Daniel

Re: 2.5.26 hotplug failure

[Daniel Phillips]

On Thursday 19 September 2002 09:37, Daniel Phillips wrote:
> On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > Sorry, but I'm not going to put the file back.  I understand your
> > concerns.  We should have some kind of program (lsdev like) that shows
> > the system information present at that moment in time.  It will be able
> > to provide what the /proc/bus/usb/drivers file showed in the past.
> 
> How about calling it /proc/bus/usb/drivers?

Never mind, /usr/sbin/lsusb or whatever is the obvious model.  Still,
it's interesting to think about a proc stub that just calls a user
space program.

-- 
Daniel

Re: 2.5.26 hotplug failure

[Greg KH]

On Thu, Sep 19, 2002 at 09:37:07AM +0200, Daniel Phillips wrote:
> On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > Sorry, but I'm not going to put the file back.  I understand your
> > concerns.  We should have some kind of program (lsdev like) that shows
> > the system information present at that moment in time.  It will be able
> > to provide what the /proc/bus/usb/drivers file showed in the past.
> 
> How about calling it /proc/bus/usb/drivers?

Please go back and read what I wrote above what you snipped out and then
explain how this would be possible.

greg k-h

Re: 2.5.26 hotplug failure

[Daniel Phillips]

On Thursday 19 September 2002 09:48, Greg KH wrote:
> On Thu, Sep 19, 2002 at 09:37:07AM +0200, Daniel Phillips wrote:
> > On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > > Sorry, but I'm not going to put the file back.  I understand your
> > > concerns.  We should have some kind of program (lsdev like) that shows
> > > the system information present at that moment in time.  It will be able
> > > to provide what the /proc/bus/usb/drivers file showed in the past.
> > 
> > How about calling it /proc/bus/usb/drivers?
> 
> Please go back and read what I wrote above what you snipped out and then
> explain how this would be possible.

I don't get it.  What's the problem?  Not that I'm advocating that proc have
functionality that can be done perfectly well in user space, but I fail to
see why you couldn't do it in proc if you wanted to.

-- 
Daniel

Re: 2.5.26 hotplug failure

[Greg KH]

On Thu, Sep 19, 2002 at 09:55:57AM +0200, Daniel Phillips wrote:
> On Thursday 19 September 2002 09:48, Greg KH wrote:
> > On Thu, Sep 19, 2002 at 09:37:07AM +0200, Daniel Phillips wrote:
> > > On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > > > Sorry, but I'm not going to put the file back.  I understand your
> > > > concerns.  We should have some kind of program (lsdev like) that shows
> > > > the system information present at that moment in time.  It will be able
> > > > to provide what the /proc/bus/usb/drivers file showed in the past.
> > > 
> > > How about calling it /proc/bus/usb/drivers?
> > 
> > Please go back and read what I wrote above what you snipped out and then
> > explain how this would be possible.
> 
> I don't get it.  What's the problem?  Not that I'm advocating that proc have
> functionality that can be done perfectly well in user space, but I fail to
> see why you couldn't do it in proc if you wanted to.

First of all, /proc/bus/usb/* is not a proc filesystem, usbfs is mounted
in that location :)

The main reason is this information is no longer available to the USB
core.  It isn't keeping a list of registered drivers anymore, only the
driver core is.  So there's no way that usbfs can get to that
information.  As the info is available in driverfs, duplication of it in
usbfs would be bloat.

thanks,

greg k-h

Re: 2.5.26 hotplug failure

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 20 Sep 2002 02:49, Greg KH wrote:
> The main reason is this information is no longer available to the USB
> core.  It isn't keeping a list of registered drivers anymore, only the
> driver core is.  So there's no way that usbfs can get to that
> information.  As the info is available in driverfs, duplication of it in
> usbfs would be bloat.
This doesn't follow. driverfs != driver core, just as usbfs != USB core.

I wasn't joking about putting back the /proc/bus/usb/drivers file. This is 
really going to hurt us in 2.6. 

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ijn3W6pHgIdAuOMRAmU+AKCFhvEl2SmXYiYpOQk6CDWrpZhpSACgwh3p
nczKbUd5dYb1V2Ycbk2/eRE=
=RLuK
-----END PGP SIGNATURE-----

Re: 2.5.26 hotplug failure

[Greg KH]

On Fri, Sep 20, 2002 at 06:56:23AM +1000, Brad Hards wrote:
> On Fri, 20 Sep 2002 02:49, Greg KH wrote:
> > The main reason is this information is no longer available to the USB
> > core.  It isn't keeping a list of registered drivers anymore, only the
> > driver core is.  So there's no way that usbfs can get to that
> > information.  As the info is available in driverfs, duplication of it in
> > usbfs would be bloat.
> This doesn't follow. driverfs != driver core, just as usbfs != USB core.

I agree.  But the info is now in the driver core, it's not present in
the USB core at all anymore.  So since drverfs exports what's in the
driver core, that info shows up there.  usbfs doesn't have access to
this info, so it can't display it.

> I wasn't joking about putting back the /proc/bus/usb/drivers file. This is 
> really going to hurt us in 2.6. 

Is this file _really_ used?  All it did was show the USB drivers
registered.  Even so, that same information is now present in driverfs,
I haven't taken away anything, just moved it.  Lots of things are
starting to move to driverfs, this isn't the first, and will not be the
last.

thanks,

greg k-h

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[David Brownell]

>>I wasn't joking about putting back the /proc/bus/usb/drivers file. This is 
>>really going to hurt us in 2.6. 

Considering that the main use of that file that I know about was
implicit (usbfs is available if its files are present, another
assumption broken in 2.5), I'm not sure I feel any pain... :-)


> Is this file _really_ used?  All it did was show the USB drivers
> registered.  Even so, that same information is now present in driverfs,
> I haven't taken away anything, just moved it.  Lots of things are
> starting to move to driverfs, this isn't the first, and will not be the
> last.

Actually it does more than that ... it tells you what minor numbers
are assigned to the drivers _currently loaded_ which means that it's
not really useful the instant someone plugs in another device.

You can't use it to allocate numbers or tell what /dev/file/name matches
a given device ... so what is its value, other than providing a limited
minor number counterpart to /proc/devices?  (Which, confusingly, doesn't
list devices but major numbers.)

- Dave

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Greg KH]

On Fri, Sep 20, 2002 at 01:42:50PM -0700, David Brownell wrote:
> 
> Actually it does more than that ... it tells you what minor numbers
> are assigned to the drivers _currently loaded_ which means that it's
> not really useful the instant someone plugs in another device.

Wait, I'm confused, which one is "it"?  The old /proc/bus/usb/drivers
file, or the new driverfs stuff?

> You can't use it to allocate numbers or tell what /dev/file/name matches
> a given device ... so what is its value, other than providing a limited
> minor number counterpart to /proc/devices?  (Which, confusingly, doesn't
> list devices but major numbers.)

I'm working on adding the minor number info to the usb driverfs code
right now, so that info will be available. 

thanks,

greg k-h

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 21 Sep 2002 06:42, David Brownell wrote:
> >>I wasn't joking about putting back the /proc/bus/usb/drivers file. This
> >> is really going to hurt us in 2.6.
>
> Considering that the main use of that file that I know about was
> implicit (usbfs is available if its files are present, another
> assumption broken in 2.5), I'm not sure I feel any pain... :-)
OK. Everytime someone goes "I've got usbfs loaded, and here is 
/proc/bus/usb/devices, but can't send you /proc/bus/usb/drivers", I'll assume 
that you two will answer the question.

Helping people is hard. Please don't make it harder. :-(

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9i63BW6pHgIdAuOMRAmylAKCFgC9OMHhzzLT9ac+Z+YHSNkn0IACeJsCe
MxFG9+07RZh1QnDAE27/FqI=
=vwfj
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Johannes Erdfelt]

On Sat, Sep 21, 2002, Brad Hards <bhards@bigpond.net.au> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 21 Sep 2002 06:42, David Brownell wrote:
> > >>I wasn't joking about putting back the /proc/bus/usb/drivers file. This
> > >> is really going to hurt us in 2.6.
> >
> > Considering that the main use of that file that I know about was
> > implicit (usbfs is available if its files are present, another
> > assumption broken in 2.5), I'm not sure I feel any pain... :-)
> 
> OK. Everytime someone goes "I've got usbfs loaded, and here is 
> /proc/bus/usb/devices, but can't send you /proc/bus/usb/drivers", I'll assume 
> that you two will answer the question.
> 
> Helping people is hard. Please don't make it harder. :-(

Personally, I've never used /proc/bus/usb/drivers. I've always just
looked at lsmod.

Why should this be any different?

JE

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Patrick Mochel]

On Sat, 21 Sep 2002, Brad Hards wrote:

> On Sat, 21 Sep 2002 06:42, David Brownell wrote:
> > >>I wasn't joking about putting back the /proc/bus/usb/drivers file. This
> > >> is really going to hurt us in 2.6.
> >
> > Considering that the main use of that file that I know about was
> > implicit (usbfs is available if its files are present, another
> > assumption broken in 2.5), I'm not sure I feel any pain... :-)
> OK. Everytime someone goes "I've got usbfs loaded, and here is
> /proc/bus/usb/devices, but can't send you /proc/bus/usb/drivers", I'll assume
> that you two will answer the question.
> 
> Helping people is hard. Please don't make it harder. :-(

We definitely don't want to make it harder, for users or developers. We're 
actually trying to make it easier for both, even though it may not be 
apparent right now. 

Converting code to the driver model means we get to consolidate a lot of 
similar yet disparate interfaces and code, which most people seem to 
favor. 

As far as userspace goes, there are tools being developed to extract 
data from driverfs, to give users easy access to device and driver 
attributes; the stuff that was encoded in various proc files. With these 
tools, $user should be able to extract $data for $developer WRT $object. 

And, they should work identically for any instance of an object type 
that's encoded in driverfs: all devices or all bus types or all class 
types, etc, will behave identicaly and give similar data. 

For example, to extract the data you mention above, it would be something 
like: 

	$ lsbus usb devices > usb.info
	$ lsbus usb drivers >> usb.info

No, they're not done, and so I'm all talk about at this point. But, this 
has been the plan all along..

	-pat

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Randy.Dunlap]

On Fri, 20 Sep 2002, Johannes Erdfelt wrote:

| On Sat, Sep 21, 2002, Brad Hards <bhards@bigpond.net.au> wrote:
| > -----BEGIN PGP SIGNED MESSAGE-----
| > Hash: SHA1
| >
| > On Sat, 21 Sep 2002 06:42, David Brownell wrote:
| > > >>I wasn't joking about putting back the /proc/bus/usb/drivers file. This
| > > >> is really going to hurt us in 2.6.
| > >
| > > Considering that the main use of that file that I know about was
| > > implicit (usbfs is available if its files are present, another
| > > assumption broken in 2.5), I'm not sure I feel any pain... :-)
| >
| > OK. Everytime someone goes "I've got usbfs loaded, and here is
| > /proc/bus/usb/devices, but can't send you /proc/bus/usb/drivers", I'll assume
| > that you two will answer the question.
| >
| > Helping people is hard. Please don't make it harder. :-(
|
| Personally, I've never used /proc/bus/usb/drivers. I've always just
| looked at lsmod.
|
| Why should this be any different?

The only case I know of that's it been useful is to see why
some USB driver failed registration -- because it's minor number(s)
were already assigned/registered.  That won't happen with
just kernel.org stock drivers etc., of course.

-- 
~Randy

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 21 Sep 2002 09:36, Johannes Erdfelt wrote:
> Personally, I've never used /proc/bus/usb/drivers. I've always just
> looked at lsmod.
>
> Why should this be any different?
Because lsmod only works for drivers that are modular. Real users mix built-in 
and modules.

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9i7yXW6pHgIdAuOMRAhaVAJ9r7DqZ8N5Zyq/V2TCKfnFDEYC1awCghryW
sx2q98LjfXpiSgzW0gGPZC4=
=mzPE
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[David Brownell]

>>Personally, I've never used /proc/bus/usb/drivers. I've always just
>>looked at lsmod.
>>
>>Why should this be any different?
> 
> Because lsmod only works for drivers that are modular. Real users mix built-in 
> and modules.

Wasn't someone -- Rusty? -- working an update to the module framework
so 2.5 would be able to show all kernel modules, not just dynamically
linked ones?  And so something like their MODULE_NAME could be used
in static tables as the driver name?  Some 2.4 usb drivers disagreed
with themselves on that issue.  (Hotplug no longer has the table of
exceptions it once had, it was error prone.  But that also means it's
more uncertain about system state than is necessary.)

I'd be more keen to see that issue solved than keep the 'drivers' file.
The question that hotplug wants to answer, for example, is "is this
driver in the kernel".  None of the 2.4 solutions for that were very
trouble free.

- Dave

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[David Brownell]

Greg KH wrote:
> On Fri, Sep 20, 2002 at 01:42:50PM -0700, David Brownell wrote:
> 
>>Actually it does more than that ... it tells you what minor numbers
>>are assigned to the drivers _currently loaded_ which means that it's
>>not really useful the instant someone plugs in another device.
> 
> 
> Wait, I'm confused, which one is "it"?  The old /proc/bus/usb/drivers
> file, or the new driverfs stuff?

The old file.


>>You can't use it to allocate numbers or tell what /dev/file/name matches
>>a given device ... so what is its value, other than providing a limited
>>minor number counterpart to /proc/devices?  (Which, confusingly, doesn't
>>list devices but major numbers.)
> 
> 
> I'm working on adding the minor number info to the usb driverfs code
> right now, so that info will be available. 

How about a facility to create the character (or block?) special file
node right there in the driverfs directory?  Optional of course.

The deal being that we really don't want to care at all about major
or minor numbers.  If you only add minor, major remains an issue.
If you add both, then the problem is where to find the darn device
special file.  If you add the device (special) file ... then it's easy
for device drivers to migrate!  'devlabel' or somesuch could manage
symlinks to "user friendly names" using class level hotplug events,
and smarter apps would start to scan driverfs directly.

- Dave

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Greg KH]

On Fri, Sep 20, 2002 at 07:55:22PM -0700, David Brownell wrote:
> 
> How about a facility to create the character (or block?) special file
> node right there in the driverfs directory?  Optional of course.

No, Linus has stated that this is not ok to do.  See the lkml archives
for the whole discussion about this.

thanks,

greg k-h

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[David Brownell]

Greg KH wrote:
> On Fri, Sep 20, 2002 at 07:55:22PM -0700, David Brownell wrote:
> 
>>How about a facility to create the character (or block?) special file
>>node right there in the driverfs directory?  Optional of course.
> 
> 
> No, Linus has stated that this is not ok to do.  See the lkml archives
> for the whole discussion about this.

I suspected that'd be the case.  Some pointer into the archives
would be good, though I'd suspect the basic summary is that it'd
be too much like devfs that way.  Did the same statement apply to
adding some file that wasn't a device special file?  That kind
of solution moves in the "no majors/minors" direction, which I
thought was the general goal.  Leaves a naming policy debate,
but one that ought to be more managable (say, with devlabel).

Though I guess my original reaction still stands then:  I don't
much want to care about major/minor numbers, so why not just leave
them out in favor of whatever better solution is the goal?  Save
everyone the intermediate steps!

- Dave

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Greg KH]

On Fri, Sep 20, 2002 at 08:58:09PM -0700, David Brownell wrote:
> Greg KH wrote:
> >On Fri, Sep 20, 2002 at 07:55:22PM -0700, David Brownell wrote:
> >
> >>How about a facility to create the character (or block?) special file
> >>node right there in the driverfs directory?  Optional of course.
> >
> >
> >No, Linus has stated that this is not ok to do.  See the lkml archives
> >for the whole discussion about this.
> 
> I suspected that'd be the case.  Some pointer into the archives
> would be good, though I'd suspect the basic summary is that it'd
> be too much like devfs that way.  Did the same statement apply to
> adding some file that wasn't a device special file?  That kind
> of solution moves in the "no majors/minors" direction, which I
> thought was the general goal.  Leaves a naming policy debate,
> but one that ought to be more managable (say, with devlabel).

All naming policies are moving to userspace.  It will not be a kernel
issue.

> Though I guess my original reaction still stands then:  I don't
> much want to care about major/minor numbers, so why not just leave
> them out in favor of whatever better solution is the goal?  Save
> everyone the intermediate steps!

No, we need the major/minor number to be in driverfs.  That way the
userspace program (that's running the naming policy) can look at
driverfs to see what devices are present, what the major/minor number of
the device is, what type of device it is, and then create the /dev node
for the device, based on that information.

We are slowly getting there, and I don't see any intermediate steps
along the way (meaning ones that get ripped out later.)

thanks,

greg k-h

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Linus Torvalds]

In article <20020921033137.GA26017@kroah.com>, Greg KH  <greg@kroah.com> wrote:
>On Fri, Sep 20, 2002 at 07:55:22PM -0700, David Brownell wrote:
>> 
>> How about a facility to create the character (or block?) special file
>> node right there in the driverfs directory?  Optional of course.
>
>No, Linus has stated that this is not ok to do.  See the lkml archives
>for the whole discussion about this.

I'm not totally against it, it's just that it has some issues:

 - naming policy in general. Trivially handled by just always calling
   the special node something truly boring and nautral like "node", and
   be done with it. The _path_ is the real name, the "node" would be
   just an openable entity.

 - the issue of persistent permissions and ownership. 

The latter is the real problem.  And I personally think the only sane
policy is to just let "/sbin/hotplug" handle it, which definitely
implies _not_ having the kernel create the real device node. That way
user-space can have any policy it damn well pleases, including having
some default heuristics along with "a priori known nodes".

But clearly that user-space hotplug entity needs to know major and minor
numbers in order to create the real device node, and that's where the
"node" thing may be acceptable - as a template, nothing more.  Although
I suspect that there are other, simpler and more acceptable templates
(ie export the dang thing as just a "node" text-file, which describes
the majors and minors and "char vs block" issues)

		Linus

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6494 bytes --]


On Sun, 22 Sep 2002, Linus Torvalds wrote:

> In article <20020921033137.GA26017@kroah.com>, Greg KH  <greg@kroah.com> wrote:
> >On Fri, Sep 20, 2002 at 07:55:22PM -0700, David Brownell wrote:
> >> 
> >> How about a facility to create the character (or block?) special file
> >> node right there in the driverfs directory?  Optional of course.
> >
> >No, Linus has stated that this is not ok to do.  See the lkml archives
> >for the whole discussion about this.
> 
> I'm not totally against it, it's just that it has some issues:
> 
>  - naming policy in general. Trivially handled by just always calling
>    the special node something truly boring and nautral like "node", and
>    be done with it. The _path_ is the real name, the "node" would be
>    just an openable entity.
> 
>  - the issue of persistent permissions and ownership. 
> 
> The latter is the real problem.  And I personally think the only sane
> policy is to just let "/sbin/hotplug" handle it, which definitely
> implies _not_ having the kernel create the real device node. That way
> user-space can have any policy it damn well pleases, including having
> some default heuristics along with "a priori known nodes".
> 
> But clearly that user-space hotplug entity needs to know major and minor
> numbers in order to create the real device node, and that's where the
> "node" thing may be acceptable - as a template, nothing more.  Although
> I suspect that there are other, simpler and more acceptable templates
> (ie export the dang thing as just a "node" text-file, which describes
> the majors and minors and "char vs block" issues)

The concern that I had was that people would actually start using the 
stupid thing, and start to rely on the path and existence of them. But, I 
suppose if people really _want_ to do that, we shouldn't stop them from 
hurting themselves. ;)

Userspace does need to know major/minor, as well as block vs. char. We 
could encode those in one file each, but a device node gives us all three 
in a standard format. 

So, appended is a patch that allows you to create a device node in 
driverfs. The API is:

int device_create_node(struct device *device, mode_t mode, kdev_t kdev);

The name is "node", and it's created in the device's directory. There are 
plans to call /sbin/hotplug after the device is registered with its class. 
It's then that the kernel will know what type of device it is, and what 
the major/minor should be. The device path will be passed to 
/sbin/hotplug, which can then query the node as a template for creating 
other device nodes. 

Note that ->fops is not set, though it appears that a request_module()  
happpens when you try to write to it.

Also, the owner of the device is root, and I easily make the permissions 
more stringent (i.e. make it S_IRUGO only always).

Attached is a simple little module to illustrate the use of the API. It 
creates a device 'foo0' and a node inside its directory once registered:

# tree /sys/root/foo0/
/sys/root/foo0/
|-- name
|-- node
`-- power


# ls -l /sys/root/foo0/node 
cr--r--r--    1 root     root      10,  16 Sep 23 10:58 
/sys/root/foo0/node


Will submit as a BK patch pending feedback..


	-pat


===== drivers/base/fs/device.c 1.20 vs edited =====
--- 1.20/drivers/base/fs/device.c	Mon Aug 26 08:39:22 2002
+++ edited/drivers/base/fs/device.c	Tue Sep 24 10:47:48 2002
@@ -80,6 +80,24 @@
 };
 
 /**
+ * device_create_node - create a device node for a device
+ * @dev:	device we're creating the node for
+ * @mode:	permissions of the device
+ * @kdev:	major/minor of the device
+ *
+ */
+int device_create_node(struct device * dev, mode_t mode, kdev_t kdev)
+{
+	struct attribute attr = {
+		.name	= "node",
+		.mode	= mode,
+	};
+	printk("creating node (kdev = %d, mode = %d, dev = %s)\n",
+	       kdev_t_to_nr(kdev),mode,dev->bus_id);
+	return driverfs_create_node(&attr,&dev->dir,kdev);
+}
+
+/**
  * device_create_file - create a driverfs file for a device
  * @dev:	device requesting file
  * @entry:	entry describing file
@@ -243,3 +261,4 @@
 
 EXPORT_SYMBOL(device_create_file);
 EXPORT_SYMBOL(device_remove_file);
+EXPORT_SYMBOL(device_create_node);
===== fs/driverfs/inode.c 1.50 vs edited =====
--- 1.50/fs/driverfs/inode.c	Wed Sep 11 13:47:46 2002
+++ edited/fs/driverfs/inode.c	Tue Sep 24 10:51:26 2002
@@ -145,8 +145,6 @@
 	if (dentry->d_inode)
 		return -EEXIST;
 
-	/* only allow create if ->d_fsdata is not NULL (so we can assume it 
-	 * comes from the driverfs API below. */
 	inode = driverfs_get_inode(dir->i_sb, mode, dev);
 	if (inode) {
 		d_instantiate(dentry, inode);
@@ -598,6 +596,30 @@
 	up(&parent->dentry->d_inode->i_sem);
 	return error;
 }
+
+int driverfs_create_node(struct attribute * attr, 
+			 struct driver_dir_entry * parent, kdev_t kdev)
+{
+	struct dentry * dentry;
+	int error = 0;
+
+	if (!attr || !parent)
+		return -EINVAL;
+
+	if (!parent->dentry)
+		return -EINVAL;
+
+	down(&parent->dentry->d_inode->i_sem);
+	dentry = get_dentry(parent->dentry,attr->name);
+	if (!IS_ERR(dentry)) {
+		error = driverfs_mknod(parent->dentry->d_inode,dentry,
+				       attr->mode,kdev_t_to_nr(kdev));
+	} else
+		error = PTR_ERR(dentry);
+	up(&parent->dentry->d_inode->i_sem);
+	return error;
+}
+
 
 /**
  * driverfs_create_symlink - make a symlink
===== include/linux/device.h 1.38 vs edited =====
--- 1.38/include/linux/device.h	Mon Sep 23 18:23:03 2002
+++ edited/include/linux/device.h	Tue Sep 24 11:01:26 2002
@@ -346,6 +346,8 @@
 extern int device_create_file(struct device *device, struct device_attribute * entry);
 extern void device_remove_file(struct device * dev, struct device_attribute * attr);
 
+extern int device_create_node(struct device *device, mode_t mode, kdev_t kdev);
+
 /*
  * Platform "fixup" functions - allow the platform to have their say
  * about devices and actions that the general device layer doesn't
===== include/linux/driverfs_fs.h 1.13 vs edited =====
--- 1.13/include/linux/driverfs_fs.h	Thu Aug  1 12:07:33 2002
+++ edited/include/linux/driverfs_fs.h	Tue Sep 24 10:54:16 2002
@@ -26,6 +26,8 @@
 #ifndef _DRIVER_FS_H_
 #define _DRIVER_FS_H_
 
+#include <linux/kdev_t.h>
+
 struct driver_dir_entry;
 struct attribute;
 
@@ -57,6 +59,10 @@
 extern int
 driverfs_create_file(struct attribute * attr,
 		     struct driver_dir_entry * parent);
+
+
+extern int driverfs_create_node(struct attribute * attr, 
+				struct driver_dir_entry * parent, kdev_t kdev);
 
 extern int 
 driverfs_create_symlink(struct driver_dir_entry * parent, 

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1402 bytes --]

/*
 * foodev.c - simple illustration of device node creation in driverfs.
 *
 * Copyright (c) 2002 Patrick Mochel
 *
 * This is simple and stupid. We declare a platform device, register it
 * with the system, then create a device node for it.
 * The major/minor used is the char misc device, and the first free minor
 * (right after the mk712 touchscreen; stupid mk712).
 *
 * This is very buggy, but it's not meant to be perfect. We should check
 * the return of the registration and creation functions. 
 * And, the module can be unloaded while there are still references to 
 * the device. Oh well..
 * 
 * Also, the device has no parent or bus. Don't do that. Ever. I wrote 
 * the API, so I'm special. ;)
 *
 * Compiled with:

CFLAGS = -Wall -O2 -fomit-frame-pointer -DMODULE -D__KERNEL__
IDIR = /home/mochel/src/kernel/devel/linux-2.5/include

foodev.o:: 
	$(CC) $(CFLAGS) -I$(IDIR) -c -o $@ $<

 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/init.h>

static struct device foodev = {
	.bus_id	= "foo0",
	.name	= "The Foo Device",
};

static int __init foodev_init(void)
{
	device_register(&foodev);
	device_create_node(&foodev,(S_IFCHR|S_IRUGO),mk_kdev(10,16));
	return 0;
}

static void __exit foodev_exit(void)
{
	put_device(&foodev);
}

module_init(foodev_init);
module_exit(foodev_exit);

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Linus Torvalds]

On Tue, 24 Sep 2002, Patrick Mochel wrote:
> 
> Also, the owner of the device is root, and I easily make the permissions 
> more stringent (i.e. make it S_IRUGO only always).

Well, that would _have_ to be the case, right now you give read access to 
every single device exported this way. Not acceptable.

I really suspect that it would be better to not export the device itself,
but export just device data. In particular, that avoids the security
issues altogether, and it's most likely what a hotplug agent really wants
anyway (and the pure node is useless without a hotplug agent, as the
default kernel permissions would have to be so anal as to make it not
interesting).

So I'd suggest you just export a text-file that describes the thing. 
Something like

 - legacy name (the kernel knows about these anyway, see /proc/mounts and 
   friends)
 - major number, minor number) and char vs block

that way a simple script can just basically do the equivalent of "MAKEDEV" 
at hotplug time using the legacy name as a key to whatever permission and 
ownership heuristics it has (the way MAKEDEV already does)

		Linus

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Greg KH]

On Tue, Sep 24, 2002 at 11:55:00AM -0700, Linus Torvalds wrote:
> 
> So I'd suggest you just export a text-file that describes the thing. 
> Something like
> 
>  - legacy name (the kernel knows about these anyway, see /proc/mounts and 
>    friends)

I would like to see all of the /proc/mounts and friends info that
"knows" about the legacy name, to disappear if possible.  Yes, I know
the root filesystem logic will have to stay, but I don't want to see
this be used like the devfs name is used throughout the kernel.  That
info should not be in the kernel, it's up to the user what to name their
"USB mouse, connected to the EHCI host controller's 3 hub port".

>  - major number, minor number) and char vs block

Yes, this info is needed, and if presented in a file, that would be
fine.  It was just that the device node was a nice compact version of
this :)
But I can see how the device node would be abused, and it's fine with me
if it isn't present in driverfs.

thanks,

greg k-h

Re: [linux-usb-devel] Re: 2.5.26 hotplug failure

[Patrick Mochel]

On Tue, 24 Sep 2002, Greg KH wrote:

> On Tue, Sep 24, 2002 at 11:55:00AM -0700, Linus Torvalds wrote:
> > 
> > So I'd suggest you just export a text-file that describes the thing. 
> > Something like
> > 
> >  - legacy name (the kernel knows about these anyway, see /proc/mounts and 
> >    friends)
> 
> I would like to see all of the /proc/mounts and friends info that
> "knows" about the legacy name, to disappear if possible.  Yes, I know
> the root filesystem logic will have to stay, but I don't want to see
> this be used like the devfs name is used throughout the kernel.  That
> info should not be in the kernel, it's up to the user what to name their
> "USB mouse, connected to the EHCI host controller's 3 hub port".

I agree. We can create a file in userspace that the hotplug agent can 
query for what to name the device. It's gonna have to do this anyway, for 
user-defined policy. Putting the legacy name in that puts all names in 
one place. 

> >  - major number, minor number) and char vs block
> 
> Yes, this info is needed, and if presented in a file, that would be
> fine.  It was just that the device node was a nice compact version of
> this :)

Exactly. If we go with a text file, and we enforce our own 1 value/file 
semantics, we end up with a file for each:

- major
- minor
- type (char vs. block)
- legacy name

If we punt the legacy name to userspace, a device node becomes ideal for 
expressing the data. 

> But I can see how the device node would be abused, and it's fine with me
> if it isn't present in driverfs.

I didn't even want it in the first place. ;) But, it's a lot easier to 
express the data /sbin/hotplug needs than three separate files. 

Also note that there may be multiple 'node' files (or equivalent) for 
devices that support multiple interfaces. E.g. mice in the input layer 
have an general event device and a mouse event device. The patch I posted 
wouldn't work, since the name is hardcoded to 'node'. But, it would be 
trival to append or prepend the name of the interface to 'node'. 

We could do that for each of the text files, but that would unnecessarily 
clutter the device's directory.

As far as abuse, we could force the permissions to 000, which would still 
allow us to stat the device. We appear to still do a request_module() on 
open(), but read() and write() should fail..


	-pat