[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: bogous binfmt_misc patch in 2.2.0-pre1
From:       Arjan van de Ven <arjan () fenrus ! demon ! nl>
Date:       1999-01-02 11:10:34
[Download RAW message or body]

On Fri, 1 Jan 1999, Linus Torvalds wrote:

> 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/

[prev in list] [next in list] [prev in thread] [next in thread]