driverfs question
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
Quoted 19 lines · 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
Quoted 8 lines
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.
Quoted 4 lines
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
Quoted 2 lines · Adam
All devices will be arranged according to type. There will be a folder
^^^^^
Quoted 2 lines
Method 2:
Folders are created for each bus then devices are placed within them.
^^^^^^^
Quoted 1 line
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
Quoted 23 lines · [email protected] wrote:
Quoted 2 lines · Adam
All devices will be arranged according to type. There will be a folder
^^^^^Quoted 3 lines
Method 2:
Folders are created for each bus then devices are placed within them.^^^^^^^
Quoted 2 lines
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.
Quoted 8 lines
Cheers,
Dick JohnsonPenguin : 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, 21 Feb 2002, Adam wrote:
[SNIPPED..]
Quoted 8 lines
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
Quoted 3 lines · 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.
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
Followup to: <[email protected]> By author: Adam <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines
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
Signature · 3 lines
<[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]>