Date: Mon, 29 Nov 1999 14:49:00 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Warner Losh <imp@village.org> Cc: Dan Moschuk <dan@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <199911292249.OAA12040@apollo.backplane.com> References: <199911292221.OAA11475@apollo.backplane.com> <199911292202.OAA09817@apollo.backplane.com> <19991129161327.E2999@spirit.jaded.net> <199911281751.JAA40710@freefall.freebsd.org> <199911292104.NAA09106@apollo.backplane.com> <199911292200.PAA95264@harmony.village.org> <199911292214.PAA97196@harmony.village.org> <199911292235.PAA97412@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:NFS is on the install boot disk. Some minor efforts on nfs could
:result in a savings of more than 686 bytes. We'd get a larger bang
:for the buck loading the firmware for drivers, reducing the verbosity
:of messages, etc.
While I agree we can further option out the NFS code, NFS happens to be
extremely *useful* on a boot disk. Before I started using CD's I used
the NFS option all the time to slave from another working machine in
order to get access to a full / and /usr.
Arguably, NFS is much more useful on a boot disk then, say, security
options for pid and source port.
:We're at the level where > 1k should be the threshold. Many changes
:in the kernel have > 1k. look at kern_ntptime.o. It is approx 2.5k,
:but not optional. Other example could be found in that same size
kern_ntptime is not optional simply because a huge number of people
use it, because there are options in rc.conf that need it (xntpd
for example), and because the core facilities provided by ntptime
are necessary for a number of other modules, including NFS. Have you
ever ran an NFS server with multiple clients where the clients haven't
been time synched? We didn't dare do that even back in the 80's.
:range (or bigger, look at the kernel linker at 6k)... That's the
:point I'm trying to make. There are bigger poles in this tent and we
:have't been good about marking the poles, nor in establishing policy
:for compile time vs runtime engineering decisions.
:
:Warner
But, frankly, I dont' understand your argument. If you are arguing
that there are other modules that could be optimized I don't see how
that justifies not optimizing a trivially optimized module while the
author still has his book open to it. The authors of the other modules
do not necessarily have their books open to those any more, so we are
really talking about uncompareable things here.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911292249.OAA12040>