lkml.org 
[lkml]   [2002]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: driverfs question

On Thu, 21 Feb 2002, Adam wrote:

>
> How will the devices in the driverfs be arranged?
> It seems to me that it could only be one of the following three methods.
>
> Method 1:
> All devices will be arranged according to type. There will be a folder
> for video, sound, joysticks, etc.
> Pros: - Easy to read and understand while browsing the driverfs.
> Cons: - Similar interface already implemented in device fs.
> - arrangement shows no hierarchy and doesn't involve the buses.
>
> Method 2:
> Folders are created for each bus then devices are placed within them.
> If a bus has another bus for a parent, like a pci USB controller,
> it doesn't matter. The bus still gets a root level folder.
> Pros: - Useful and unique information to the user.
> Cons: - Still doesn't truly represent devices by their actual connection
> - Makes root level device detection APIs more difficult to write
>
> Method 3:
> Devices are arranged by their true connection. If a usb controller is a
> member of a pci bus, it's folder will be within the pci folder. The
> root level bus will either be PnP BIOS, APIC device tables, or, for
> legacy computers, an emulation of some sort.
> Pros: - Devices are arranged by their actual connection.
> - PnP and APIC will finally be truly integrated into the kernel.
> Cons: - Legacy emulation could be challenging.

This is the intended method of operation, and we have so far. The PCI bus
is a child of the root; a USB bus is a child of the rest.

Legacy is emulation is interesting, since many legacy devices just
"appear" on the system bus. The method I have suggested for this to create
a 'legacy bus' that parents all legacy devices found in the system.

> I tend to prefer method 3. Not only does it provide a perfect interface
> for user level daemons but also it shows the devices in their true
> locations. This is very important. Perhaps all or some of these
> methods should be compile time options.

The other methods can be wrapped into userspace utilities, if one so
desires. Some of them already are. There are 'lspci' and 'lsusb'
utilities.

A device typically knows what device class it belongs to, though this
information is not represented in struct device currently. If it was, one
could theoretically do 'lsvideo' (or 'lsdev -c video') to see what video
devices they had in their system. :)

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

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.046 / U:2.936 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site