>> Most Unix tools include basic sanity checks, and that's one area
>> where the Linux kernel could be improved. The following sanity
>> check should not be that hard to do:
>> Q> Complain if the configuration selects file systems without also
>> Q> selecting somewhere to mount them, as there's little point to a
>> Q> kernel supporting (say) ext2 without supporting any form of
>> Q> disk drive to use it on.
>> Note that I'm not advocating that either IDE or SCSI have to be
>> selected, just that if neither is selected, then few of the file
>> systems make any sense...
> It's not that easy. You can have ext2 filesystems on ROM devices...
Only if the ROMfs is selected, whether "M" or "Y" is irrelevant...
> ...or a network block device.
You sure of that? I understood that NFS didnae use any of the other
file systems as it's a file system in its own right...
> And it should be possible to compile a kernel w/o IDE and SCSI, but
> with ext2fs and nbd.
Possible, yes - but then, it's possible to compile a kernel without
support for a.out or ELF - whether such is sensible is another
question...
> If you want to put a warning for this case, OK, go ahead.
That's all I was referring to anyway...
>> Likewise, a kernel compiled with NFS support but without
>> networking support doesn't make a great deal of sense, but appears
>> selectable; I can't check at the moment, so can't be sure re that
>> at this point...
> ... and the needed modules can still be added and inserted.
Even if the relevant options were selected "N" when configuring the
kernel? That's not my understanding.
> The modules add significant complexity to your sanity checks.
Why?
IMHO all the sanity check needs to deal with is whether or not options
are set as "n" which in each case is a Yes/No decision. As an example,
have a look at the following, which generates an error if the a.out
and ELF executable formats are both set "n" since the resulting kernel
is rather less than useless...
===8<=== CUT ===>8===
--- linux/arch/i386/config.in~ Mon May 13 05:17:23 1996
+++ linux/arch/i386/config.in Thu Dec 3 22:14:45 1998
@@ -36,6 +36,12 @@
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
fi
+if [ "$CONFIG_BINFMT_AOUT $CONFIG_BINFMT_ELF" = "n n" ]; then
+ echo '*** ERROR: Either a.out or ELF format is' \
+ 'ESSENTIAL for Linux to work.' >&2
+ echo ' Aborting configuration.' >&2
+ exit 1
+fi
bool 'Compile kernel as ELF - if your GCC is ELF-GCC' CONFIG_KERNEL_ELF
choice 'Processor type' \
===8<=== CUT ===>8===
Perhaps you could advise what's complicated about that...
> There are so many ways to screw your system if you are root and
> don't think enough before you are doing something. Un*x is about
> saving the user from doing stupid things but not root.
Why not root? We already include some checks to prevent root from
doing stupid things - for example, the kernel refuses to compile if
the compiler used is too early a version - and I can see nothing wrong
with putting in checks for other insane choices for precicely the same
reason - to reduce the bug reports caused by setting such insane
choices in the first place.
> If there are easy and obviously correct sanity checks (when you do
> something which never makes sense), then add a warning or error
> message.
Precicely what I said in the email you appear to take such exception
to, so what's the problem with doing that?
> In the kernel configuration process, there aren't many such cases,
> which aren't already prevented, IMHO.
{Shrug} The above case thereof was discovered with less than five
minutes study of the options presented by "make menuconfig", so is
hardly hidden. If such an obvious case is so readily apparent, then
there must be MANY more subtle ones...
> I don't think, Linus will accept anything apart from cases, where
> it's obvious, that this configuration won't be any good.
I wouldnae think as much of him as I do if he accepted anything more
than that anyway, so I can't say that worries me...
Best wishes from Riley.
-
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/