Messages in this thread | | | Date | Thu, 23 Sep 1999 09:33:13 -0500 (CDT) | From | "Edward S. Marshall" <> | Subject | Re:RFC: Get rid of CONFIG_PROC_FS, was Re: "CONFIG_PROCFS" problem , in 2.3.18ac8 |
| |
On Thu, 23 Sep 1999, Tigran Aivazian wrote: > excellent idea! The only arguments against it that I heard were "ah, but > we build embedded Linux system and every byte of memory is important". > This argument is not serious and should receive a decent reply such as > "touch, in'it?".
I think there a large number of embedded systems developers who would disagree with you about the seriousness of their needs. Both memory conservation and realtime guarantees are extremely important; the memory requirements will define a fixed cost of their device (if it's be targetted for mass production), and lowering that is a serious goal.
Remember, we still have /dev/kmem, which serves the need for access to all the same information, and does so in a much lighter-weight manner, much more suitable for low-memory and embedded systems.
> Also, all your suggestions seem excellent but I would add something > slightly more radical but, imho, also useful. How about making /proc also > mounted automatically? Sure, one can also manually mount it elsewhere as > many times as one wants but ensuring that /proc is *always* there at > /proc seems a good idea. The specific location "/proc" is part of some > standard (can't remember which) so it is not too bad to hardcode it.
This has so many problems, I don't even know where to begin.
Enforcing that /proc be mounted in a particular position at boot time has a number of side effects:
- policy: the kernel is enforcing policy on userspace, in a manner it currently doesn't do (and doesn't need to). Why force this naming convention and placement on people?
- security: /proc reveals an incredible amount of information about a system. Not everyone is as comfortable as you providing that data to all users, and as there is no pressing need in most cases to mount that in a publically-accessable location, why force it on people?
I could keep going, but I'm short on time, and I'm sure someone else will expound on this too.
-- Edward S. Marshall <emarshal@logic.net> [ What goes up, must come down. ] http://www.logic.net/~emarshal/ [ Ask any system administrator. ]
- 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/
| |