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/