>>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
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
-----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-----
On Sat, Sep 21, 2002, Brad Hards <[email protected]> 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
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
On Fri, 20 Sep 2002, Johannes Erdfelt wrote:
| On Sat, Sep 21, 2002, Brad Hards <[email protected]> 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
-----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-----