cvs commit: src/sys/alpha/alpha mem.c src/sys/alpha/conf GENERIC src/sys/alpha/include memdev.h src/sys/amd64/amd64 io.c mem.c src/sys/amd64/conf GENERIC NOTES src/sys/amd64/include iodev.h memdev.h src/sys/conf NOTES files files.alpha files.amd64 ...

[Don Lewis]

On  3 Aug, Alexey Dokuchaev wrote:
> On Mon, Aug 02, 2004 at 04:00:00PM -0400, John Baldwin wrote:

>> Why in the world are /dev/null and /dev/zero optional?  /dev/[k]mem 
>> and /dev/io I can accept for those with uber-high security paranoia, but I 
>> can't think of any good reason to have a kernel without /dev/null 
>> and /dev/zero.  To me it seems that this creates way more foot shooting 
>> potential than benefit.  It's one thing to have device drivers for hardware 
>> that may or may not be present optional, but /dev/null and /dev/zero do not 
>> fall into that case.
> 
> OTOH, if someone wants to build mega-tight kernel image with everything
> possible taken out by modules, modularizing /dev/null and /dev/zero
> might make some sence.  We already have /dev/random as a module anyways.

You might have trouble doing anything useful on the system without
/dev/null.  For instance /bin/sh won't be able to run background jobs,
/bin/csh will close stdin of any background jobs (which might cause
wierd things to happen), users of daemon(3) won't properly disconnect
from the tty which started them, and there are a number of references to
/dev/null in the /etc and /etc/rc.d scripts.

In the case of i386, the size of the text+data size of null.ko is a
little over 2K.  From a quick look at the source, it looks like at least
half of this is the module support code.

BTW, I think daemon(3) and /bin/csh should check the return value when
they attempt to open(_PATH_DEVNULL, ...).