> 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?
Yes.. And I agree almost completely. Except for binfmt_misc! (see below)
> 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.
Ah. But this thread started with the notion that disabling (through
#ifdef's, but holds also for dummy-functions) /proc for binfmt_misc is
not a good idea since it no longer is usable (you need to configure it
through /proc!). You said something like: It better generate an error than
to compile and not work, since you wouldn't know why the h*ll it doesn't
work in runtime.
For binfmt_misc, a true dependency exists, which cannot be resolved with
the current "make config". There are other cases like this, where a
"forward dependency" is the problem (*). One way of solving this is with a
"Requires" statement (Alan suggests that). I have done some preliminary
work on "Requires", a script that does this can be found at
http://www.fenrus.demon.nl/fixconfig.sh
Greetings,
Arjan van de Ven
(*) IDE-SCSI emulation and CONFIG_SCSI is such an example
(*) Radio-MIROPCM20 and ACI-MIXER is another
-
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/