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 ...
truckman at FreeBSD.org
Mon Aug 2 19:54:22 PDT 2004
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, ...).
More information about the cvs-all