Skip site navigation (1)Skip section navigation (2)
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>