I wonder if in the future, we can just eliminate /dev altogether (or map it
via sysfs until older apps move away from /dev). It just seems we could
represent major,minor in a sysfs node:
/sys/class/block/
`-- sda
|-- sda1
| - major
| - minor
| - raw
|-- sda2
| - major
| - minor
| - raw
`-- sda3
and so forth, or under a different branch elsewhere.
Does it make sense? Logical? Illogical? Do we really need /dev other than for
historical/legacy purposes?
Shawn.
El Mon, 26 Sep 2005 19:28:18 -0400,
Shawn Starr <[email protected]> escribi?:
> /sys/class/block/
> `-- sda
> |-- sda1
> | - major
> | - minor
> | - raw
With this you're adding again all the device naming linux has got ridden of
by removing devfs (it rememebers me to solaris' devfs: They have a
sysfs-like filesystem, except that things in /dev are a symbolic link to a
device file in /devices)
> Do we really need /dev other than for historical/legacy purposes?
If your intention is just to boot kernels and not run userspace on them,
then sure, it's a good idea to get rid of /dev.
Or instead of even needing major/minor we just have:
/sys/class/sound
`- - audio0
|
| - raw
`-- dsp0
|
| - raw
Then instead, let udev know that audio0 and dsp0 belong to one sound card
device or have it report this in sysfs:
/dev/class/sound
`--sound0
|
| -- dev
| -- device -> ../../../devices/pci0000:00
`-- audio0
|- device -> ../../../devices/pci0000:00/0000:00:1f.5
`--dsp0
| -device -> ../../../devices/pci0000:00/0000:00:1f.5
`--mixer0
`--sound1
|
| -dev
| -- device -> ../../../devices/pci0000:00:1a
`--audio0
|- device
--> ../../../devices/pci0000:00:1a/0000:00:1c.6
And so forth.
Then map sound0 devices in /dev/dsp0 /dev/mixer0 /dev/audio0 with udev
*NOTE: I am not avocating devfs, but more of keeping sysfs as the primary
structure for devices.
On September 26, 2005 19:28, Shawn Starr wrote: > I wonder if in the future,
we can just eliminate /dev altogether (or map it
> via sysfs until older apps move away from /dev). It just seems we could
> represent major,minor in a sysfs node:
>
> /sys/class/block/
> `-- sda
>
> |-- sda1
> |
> | - major
> | - minor
> | - raw
> |
> |-- sda2
> |
> | - major
> | - minor
> | - raw
>
> `-- sda3
>
> and so forth, or under a different branch elsewhere.
>
> Does it make sense? Logical? Illogical? Do we really need /dev other than
> for historical/legacy purposes?
>
> Shawn.
On Mon, Sep 26, 2005 at 07:28:18PM -0400, Shawn Starr wrote:
> I wonder if in the future, we can just eliminate /dev altogether (or map it
> via sysfs until older apps move away from /dev). It just seems we could
> represent major,minor in a sysfs node:
This comes up every few months. Please read the archives for why this
is not acceptable.
thanks,
greg k-h
On Mon, 26 Sep 2005, Shawn Starr wrote:
> I wonder if in the future, we can just eliminate /dev altogether (or map it
> via sysfs until older apps move away from /dev). It just seems we could
> represent major,minor in a sysfs node:
>
> /sys/class/block/
> `-- sda
> |-- sda1
> | - major
> | - minor
> | - raw
> |-- sda2
> | - major
> | - minor
> | - raw
> `-- sda3
>
> and so forth, or under a different branch elsewhere.
>
> Does it make sense? Logical? Illogical? Do we really need /dev other than for
> historical/legacy purposes?
>
> Shawn.
Already been done. We have "devfs" in the kernel. FYI, you
don't need "/dev". The devices-files are just a way of associating
a major/minor number with a file-descriptor. It's convenient and
neat to have them all at a known location, just like having
configuration files in "/etc".
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.