driverfs question

driverfs question

[Adam]

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

Re: driverfs question

[Patrick Mochel]

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

Re: driverfs question

[Richard B. Johnson]

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

Re: driverfs question

[Greg KH]

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

Re: driverfs question

[Adam]

root@chaos.analogic.com 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.

Re: driverfs question

[Richard B. Johnson]

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

Re: driverfs question

[H. Peter Anvin]

Followup to:  <3C756D06.7090901@netscape.net>
By author:    Adam <ambx1@netscape.net>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>