Sure, that makes the error much more obvious. Consider it done.
> About why not having /proc: According to Alan's buglist, there are some
> issues meaning that you don't want /proc if you can consider your users
> hostile (for example students on a university computer). Dummy-functions for
> config_proc_fs will cure this ofcourse.
It's not about not having /proc - although in a hostile environment I'd
still suggest using a standard configuration and just not _mount_ it, or
preferably mount it in a protected place so that root can still get the
"ps" output, for example.
It's about modularity: if somebody doesn't want to have /proc filesysystem
support, we should NOT have to know about that decision in other places
all over the map. We should NOT have to have
#ifdef CONFIG_PROC_FS
inside drivers/scsi/fdomain.c - do you see my point?
So what I suggested as the real fix is to leave the internal /proc
interfaces there even if /proc doesn't actually exist: that way, when
somebody disables /proc in the config, everything else will still happily
compile as if it was there, it just won't do anything.
Yes, it might cause a few unnecessary functions to be compiled that aren't
actually ever used and thus wasting a few hundred bytes of memory, but I'd
_much_ prefer a clean kernel that doesn't have to worry about spurious
config options all over the place.
Linus
-
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/