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.
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.
Sincerely,
Adam
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
On Thu, 21 Feb 2002, Adam wrote:
>
> All devices will be arranged according to type. There will be a folder
^^^^^
> Method 2:
> Folders are created for each bus then devices are placed within them.
^^^^^^^
> member of a pci bus, it's folder will be within the pci folder. The
^^^^^^ ^^^^^^
What is this? Do you mean "directory" or "file", or even "inode"?
Or is this a troll from Microsoft? We don't have such things in
real operating systems. Next thing you know, we'll need a "cabinet"
to keep the "folders" in.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
111,111,111 * 111,111,111 = 12,345,678,987,654,321
[email protected] wrote:
> On Thu, 21 Feb 2002, Adam wrote:
>
>>All devices will be arranged according to type. There will be a folder
>>
> ^^^^^
>
>>Method 2:
>>Folders are created for each bus then devices are placed within them.
>>
> ^^^^^^^
>
>
>>member of a pci bus, it's folder will be within the pci folder. The
>>
> ^^^^^^ ^^^^^^
>
> What is this? Do you mean "directory" or "file", or even "inode"?
>
> Or is this a troll from Microsoft? We don't have such things in
> real operating systems. Next thing you know, we'll need a "cabinet"
> to keep the "folders" in.
>
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
>
> 111,111,111 * 111,111,111 = 12,345,678,987,654,321
>
>
You're absolutely right. What I meant to say is a directory. It's
simply a bad habit. In fact, one, of several, reason I became
interested in the Linux kernel project is that I was unhappy with the
Micro$oft licensing policy. The term folder is used by micro$oft simply
to make it's OS sound more user friendly.
On Thu, Feb 21, 2002 at 03:37:30PM -0500, 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.
Have you looked at the current code and seen how stuff is already layed
out? It seems to match your "Method 3" already. Are you proposing the
current implementation should be changed?
thanks,
greg k-h
On Thu, 21 Feb 2002, Adam wrote:
[SNIPPED..]
>
>
> You're absolutely right. What I meant to say is a directory. It's
> simply a bad habit. In fact, one, of several, reason I became
> interested in the Linux kernel project is that I was unhappy with the
> Micro$oft licensing policy. The term folder is used by micro$oft simply
> to make it's OS sound more user friendly.
>
Thanks. I needed that. I started to worry that we had started to devolve.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
111,111,111 * 111,111,111 = 12,345,678,987,654,321
Followup to: <[email protected]>
By author: Adam <[email protected]>
In newsgroup: linux.dev.kernel
>
> You're absolutely right. What I meant to say is a directory. It's
> simply a bad habit. In fact, one, of several, reason I became
> interested in the Linux kernel project is that I was unhappy with the
> Micro$oft licensing policy. The term folder is used by micro$oft simply
> to make it's OS sound more user friendly.
>
... because, of course, that was the term Apple used.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>