Re: RFC: Get rid of CONFIG_PROC_FS, was Re: "CONFIG_PROCFS" problem in

Marcin Dalecki (dalecki@dacotec.net)
Thu, 23 Sep 1999 11:54:17 +0200


Arjan van de Ven wrote:
>
> Jeff Garzik had the wisdom to write:
> JG> When you include proc_fs.h you should not need _any_ ifdefs at all.
> JG> Inlined no-op versions of the procfs API functions are substituted when
>
> Not completely true. The functions are stubbed, but things like proc_root
> and the inode-operations aren't. Although Alan fixed the ugliest part in
> 2.1.13x, CONFIG_PROC_FS is still very ugly, and a lot of ifdef's are needed.
>
> RFC: Get rid of CONFIG_PROC_FS
>
> I hereby propose to get rid of the configuration-option CONFIG_PROC_FS and
> make the proc-filesystem mantadory.
>
> Reasons for doing so:
> 1) It cleans up a lot of code
> 2) There probably not one single sole that doesn't use procfs
> 3) The kernel _might_ build without procfs, but nobody tested if the
> stubs actually work
> 4) Codesize is hardly an issue, since the stubs also increase codesize
>
> Reasons for not doing so:
> 1) Codesize (?)
> 2) Featurefreeze
> 3) Security (?)
>
> I therefore propose to make CONFIG_PROC_FS mantadory. If the kernel-gods
> agree, I volunteer to send a patch (or more likely, a group of patches) for
> it.
>
> Any comments ?
>
> Greetings,
> Arjan van de Ven

Bad idea if running with root mounted over NFS for example.

The fact that a complete running system does in some way depend
on /proc beeing mounted is bad in itself too. This is mainly
due to the fact that all the strongly kernel
tangled userland utilities in linux are maintained separately
from the kernel source tree, and are in most cases poorly written
or maintained. (Ever took a look at the procps utils for example,
ever counted the #if KERNEL_VERSION >= in utils-linux?)

If one looks at the stuff there you can find that there far too many
/proc entries out there, which are never used or unneccessary, becouse the
attitude for the kernel beceame over the years too
be: "I don't know what to do about this parameter, oh no problem
lets make it a proc entry..." And in most cases the next step
is to invent some ugly, hardly parsable intermixed binary/text,
special, undocumented format for the new pseudo
files there, which will change with every
couple of minor kernel releases, instead of a IOCTRL or therelike.
Oh and never forget to promise to write some userland utlities
which will provide an "clean" interface for this stuff. And of course
never do it (see ide/proc, and others...)

But nobody really cares becouse nobody is really using it other then
cat /proc/interrupts cat /proc/devices during the boxes
first time setup...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/