* 2.5.26 hotplug failure @ 2002-07-18 7:50 Duncan Sands 2002-07-18 18:36 ` Greg KH 0 siblings, 1 reply; 31+ messages in thread From: Duncan Sands @ 2002-07-18 7:50 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-07-18 7:50 2.5.26 hotplug failure Duncan Sands @ 2002-07-18 18:36 ` Greg KH 2002-07-18 19:07 ` Duncan Sands 2002-09-15 21:53 ` Duncan Sands 0 siblings, 2 replies; 31+ messages in thread From: Greg KH @ 2002-07-18 18:36 UTC (permalink / raw) To: Duncan Sands; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-07-18 18:36 ` Greg KH @ 2002-07-18 19:07 ` Duncan Sands 2002-09-15 21:53 ` Duncan Sands 1 sibling, 0 replies; 31+ messages in thread From: Duncan Sands @ 2002-07-18 19:07 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-07-18 18:36 ` Greg KH 2002-07-18 19:07 ` Duncan Sands @ 2002-09-15 21:53 ` Duncan Sands 2002-09-18 6:52 ` Greg KH 1 sibling, 1 reply; 31+ messages in thread From: Duncan Sands @ 2002-09-15 21:53 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-15 21:53 ` Duncan Sands @ 2002-09-18 6:52 ` Greg KH 2002-09-18 7:15 ` [linux-usb-devel] " Brad Hards 0 siblings, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-18 6:52 UTC (permalink / raw) To: Duncan Sands; +Cc: linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-18 6:52 ` Greg KH @ 2002-09-18 7:15 ` Brad Hards 2002-09-18 16:55 ` Greg KH 0 siblings, 1 reply; 31+ messages in thread From: Brad Hards @ 2002-09-18 7:15 UTC (permalink / raw) To: Greg KH, Duncan Sands; +Cc: linux-kernel, linux-usb-devel -----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----- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-18 7:15 ` [linux-usb-devel] " Brad Hards @ 2002-09-18 16:55 ` Greg KH 2002-09-19 7:37 ` Daniel Phillips 0 siblings, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-18 16:55 UTC (permalink / raw) To: Brad Hards; +Cc: Duncan Sands, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-18 16:55 ` Greg KH @ 2002-09-19 7:37 ` Daniel Phillips 2002-09-19 7:45 ` Daniel Phillips 2002-09-19 7:48 ` Greg KH 0 siblings, 2 replies; 31+ messages in thread From: Daniel Phillips @ 2002-09-19 7:37 UTC (permalink / raw) To: Greg KH, Brad Hards; +Cc: Duncan Sands, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-19 7:37 ` Daniel Phillips @ 2002-09-19 7:45 ` Daniel Phillips 2002-09-19 7:48 ` Greg KH 1 sibling, 0 replies; 31+ messages in thread From: Daniel Phillips @ 2002-09-19 7:45 UTC (permalink / raw) To: Greg KH, Brad Hards; +Cc: Duncan Sands, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-19 7:37 ` Daniel Phillips 2002-09-19 7:45 ` Daniel Phillips @ 2002-09-19 7:48 ` Greg KH 2002-09-19 7:55 ` Daniel Phillips 1 sibling, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-19 7:48 UTC (permalink / raw) To: Daniel Phillips; +Cc: Brad Hards, Duncan Sands, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-19 7:48 ` Greg KH @ 2002-09-19 7:55 ` Daniel Phillips 2002-09-19 16:49 ` Greg KH 0 siblings, 1 reply; 31+ messages in thread From: Daniel Phillips @ 2002-09-19 7:55 UTC (permalink / raw) To: Greg KH; +Cc: Brad Hards, Duncan Sands, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-19 7:55 ` Daniel Phillips @ 2002-09-19 16:49 ` Greg KH 2002-09-19 20:56 ` Brad Hards 0 siblings, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-19 16:49 UTC (permalink / raw) To: Daniel Phillips; +Cc: Brad Hards, Duncan Sands, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-19 16:49 ` Greg KH @ 2002-09-19 20:56 ` Brad Hards 2002-09-19 23:06 ` Greg KH 0 siblings, 1 reply; 31+ messages in thread From: Brad Hards @ 2002-09-19 20:56 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel, linux-usb-devel -----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----- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.5.26 hotplug failure 2002-09-19 20:56 ` Brad Hards @ 2002-09-19 23:06 ` Greg KH 2002-09-20 20:42 ` [linux-usb-devel] " David Brownell 0 siblings, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-19 23:06 UTC (permalink / raw) To: Brad Hards; +Cc: linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-19 23:06 ` Greg KH @ 2002-09-20 20:42 ` David Brownell 2002-09-20 23:11 ` Greg KH 2002-09-20 23:22 ` Brad Hards 0 siblings, 2 replies; 31+ messages in thread From: David Brownell @ 2002-09-20 20:42 UTC (permalink / raw) To: Greg KH, Brad Hards; +Cc: linux-kernel, linux-usb-devel >>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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 20:42 ` [linux-usb-devel] " David Brownell @ 2002-09-20 23:11 ` Greg KH 2002-09-21 2:55 ` David Brownell 2002-09-20 23:22 ` Brad Hards 1 sibling, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-20 23:11 UTC (permalink / raw) To: David Brownell; +Cc: Brad Hards, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 23:11 ` Greg KH @ 2002-09-21 2:55 ` David Brownell 2002-09-21 3:31 ` Greg KH 0 siblings, 1 reply; 31+ messages in thread From: David Brownell @ 2002-09-21 2:55 UTC (permalink / raw) To: Greg KH; +Cc: Brad Hards, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-21 2:55 ` David Brownell @ 2002-09-21 3:31 ` Greg KH 2002-09-21 3:58 ` David Brownell 2002-09-22 1:21 ` Linus Torvalds 0 siblings, 2 replies; 31+ messages in thread From: Greg KH @ 2002-09-21 3:31 UTC (permalink / raw) To: David Brownell; +Cc: Brad Hards, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-21 3:31 ` Greg KH @ 2002-09-21 3:58 ` David Brownell 2002-09-21 5:48 ` Greg KH 2002-09-22 1:21 ` Linus Torvalds 1 sibling, 1 reply; 31+ messages in thread From: David Brownell @ 2002-09-21 3:58 UTC (permalink / raw) To: Greg KH; +Cc: Brad Hards, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-21 3:58 ` David Brownell @ 2002-09-21 5:48 ` Greg KH 0 siblings, 0 replies; 31+ messages in thread From: Greg KH @ 2002-09-21 5:48 UTC (permalink / raw) To: David Brownell; +Cc: Brad Hards, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-21 3:31 ` Greg KH 2002-09-21 3:58 ` David Brownell @ 2002-09-22 1:21 ` Linus Torvalds 2002-09-24 18:26 ` Patrick Mochel 1 sibling, 1 reply; 31+ messages in thread From: Linus Torvalds @ 2002-09-22 1:21 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-22 1:21 ` Linus Torvalds @ 2002-09-24 18:26 ` Patrick Mochel 2002-09-24 18:55 ` Linus Torvalds 0 siblings, 1 reply; 31+ messages in thread From: Patrick Mochel @ 2002-09-24 18:26 UTC (permalink / raw) To: Linus Torvalds; +Cc: greg, linux-kernel [-- 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); ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-24 18:26 ` Patrick Mochel @ 2002-09-24 18:55 ` Linus Torvalds 2002-09-24 19:29 ` Greg KH 0 siblings, 1 reply; 31+ messages in thread From: Linus Torvalds @ 2002-09-24 18:55 UTC (permalink / raw) To: Patrick Mochel; +Cc: greg, linux-kernel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-24 18:55 ` Linus Torvalds @ 2002-09-24 19:29 ` Greg KH 2002-09-24 22:37 ` Patrick Mochel 0 siblings, 1 reply; 31+ messages in thread From: Greg KH @ 2002-09-24 19:29 UTC (permalink / raw) To: Linus Torvalds; +Cc: Patrick Mochel, linux-kernel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-24 19:29 ` Greg KH @ 2002-09-24 22:37 ` Patrick Mochel 0 siblings, 0 replies; 31+ messages in thread From: Patrick Mochel @ 2002-09-24 22:37 UTC (permalink / raw) To: Greg KH; +Cc: Linus Torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 20:42 ` [linux-usb-devel] " David Brownell 2002-09-20 23:11 ` Greg KH @ 2002-09-20 23:22 ` Brad Hards 2002-09-20 23:36 ` Johannes Erdfelt 2002-09-20 23:46 ` Patrick Mochel 1 sibling, 2 replies; 31+ messages in thread From: Brad Hards @ 2002-09-20 23:22 UTC (permalink / raw) To: David Brownell, Greg KH; +Cc: linux-kernel, linux-usb-devel -----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----- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 23:22 ` Brad Hards @ 2002-09-20 23:36 ` Johannes Erdfelt 2002-09-21 0:11 ` Randy.Dunlap 2002-09-21 0:25 ` Brad Hards 2002-09-20 23:46 ` Patrick Mochel 1 sibling, 2 replies; 31+ messages in thread From: Johannes Erdfelt @ 2002-09-20 23:36 UTC (permalink / raw) To: Brad Hards; +Cc: David Brownell, Greg KH, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 23:36 ` Johannes Erdfelt @ 2002-09-21 0:11 ` Randy.Dunlap 2002-09-21 0:25 ` Brad Hards 1 sibling, 0 replies; 31+ messages in thread From: Randy.Dunlap @ 2002-09-21 0:11 UTC (permalink / raw) To: Johannes Erdfelt Cc: Brad Hards, David Brownell, Greg KH, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 23:36 ` Johannes Erdfelt 2002-09-21 0:11 ` Randy.Dunlap @ 2002-09-21 0:25 ` Brad Hards 2002-09-21 2:36 ` David Brownell 1 sibling, 1 reply; 31+ messages in thread From: Brad Hards @ 2002-09-21 0:25 UTC (permalink / raw) To: Johannes Erdfelt; +Cc: David Brownell, Greg KH, linux-kernel, linux-usb-devel -----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----- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-21 0:25 ` Brad Hards @ 2002-09-21 2:36 ` David Brownell 0 siblings, 0 replies; 31+ messages in thread From: David Brownell @ 2002-09-21 2:36 UTC (permalink / raw) To: Brad Hards; +Cc: Johannes Erdfelt, Greg KH, linux-kernel, linux-usb-devel >>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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [linux-usb-devel] Re: 2.5.26 hotplug failure 2002-09-20 23:22 ` Brad Hards 2002-09-20 23:36 ` Johannes Erdfelt @ 2002-09-20 23:46 ` Patrick Mochel 1 sibling, 0 replies; 31+ messages in thread From: Patrick Mochel @ 2002-09-20 23:46 UTC (permalink / raw) To: Brad Hards; +Cc: David Brownell, Greg KH, linux-kernel, linux-usb-devel 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2002-09-24 22:30 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-18 7:50 2.5.26 hotplug failure Duncan Sands 2002-07-18 18:36 ` Greg KH 2002-07-18 19:07 ` Duncan Sands 2002-09-15 21:53 ` Duncan Sands 2002-09-18 6:52 ` Greg KH 2002-09-18 7:15 ` [linux-usb-devel] " Brad Hards 2002-09-18 16:55 ` Greg KH 2002-09-19 7:37 ` Daniel Phillips 2002-09-19 7:45 ` Daniel Phillips 2002-09-19 7:48 ` Greg KH 2002-09-19 7:55 ` Daniel Phillips 2002-09-19 16:49 ` Greg KH 2002-09-19 20:56 ` Brad Hards 2002-09-19 23:06 ` Greg KH 2002-09-20 20:42 ` [linux-usb-devel] " David Brownell 2002-09-20 23:11 ` Greg KH 2002-09-21 2:55 ` David Brownell 2002-09-21 3:31 ` Greg KH 2002-09-21 3:58 ` David Brownell 2002-09-21 5:48 ` Greg KH 2002-09-22 1:21 ` Linus Torvalds 2002-09-24 18:26 ` Patrick Mochel 2002-09-24 18:55 ` Linus Torvalds 2002-09-24 19:29 ` Greg KH 2002-09-24 22:37 ` Patrick Mochel 2002-09-20 23:22 ` Brad Hards 2002-09-20 23:36 ` Johannes Erdfelt 2002-09-21 0:11 ` Randy.Dunlap 2002-09-21 0:25 ` Brad Hards 2002-09-21 2:36 ` David Brownell 2002-09-20 23:46 ` Patrick Mochel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).