Re: [PATCH] 2.5.17 /dev/ports

Martin Dalecki (dalecki@evision-ventures.com)
Thu, 23 May 2002 08:44:02 +0200


Uz.ytkownik Rusty Russell napisa?:
> On Wed, 22 May 2002 10:54:25 -0400 (EDT)
> Alexander Viro <viro@math.psu.edu> wrote:
>
>>On Wed, 22 May 2002, Alan Cox wrote:
>>
>>>XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
>>>and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
>>
>>... and while we are at flamewar-mongering, none of these files have any
>>business being in procfs.
>
>
> Let it never be said that you lack courage 8)
>
> Let's sort this out at the kernel summit:
> dev vs. driverfs. vs proc vs sysctl vs boot params vs. module params vs netlink

There isn't that much to be discussed there.

1. /proc is for process data becouse this has inherently a tree structure and
the FS abstractis is fitting this nicely. (We can share code with the VFS layer
therefore.)

2. /proc/sys is justifyed by the fact that sysctl can share a significant
amount of code with the procfs implementation. Note this *could* be changed
by abstracting the common code out of *both* procfs and sysctl instead
of stacking sysctl on to of procfs.

3. /proc/bus is superceeded by driverfs but has a tree struct and one can life
with it.

The rest is utter crap and legacy. Technically at least.

In particular the stuff listed above is looking like things which are in
reality device access abstractions and which belongs therefore to /dev/.

The only problem here is - people without taste for the implementation,
apparently love to look at files in /proc becouse this is giving them some
feelings I can't share...

PS. Did I mention that uniformity of interfaces is quite common in good
design practice? And something beeing ASCII simple doesn't imply that
it is an uniform interface.

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