> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/