Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Jan 1997 11:51:27 +1100 (EST)
From:      John Birrell <jb@cimlogic.com.au>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        current@FreeBSD.ORG
Subject:   Re: kernel w/o source? [MOD_DECL in lkm.h]
Message-ID:  <199701040051.LAA28752@freebsd1.cimlogic.com.au>
In-Reply-To: <Mutt.19970104000318.j@uriah.heep.sax.de> from J Wunsch at "Jan 4, 97 00:03:18 am"

next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch wrote:
> Define `universal'.

Default? I dunno, the crystal ball was a little fuzzy. 8-)

> Second, you can't have compile-time options anymore then.  IOW, you
> gotta include everything into the compiled object already, to make it
> run-time selectable.

I'm not sure that I agree with this. For DEBUG and DIAGNOSTIC maybe,
but most of the options involve linking in code (or not) and filling
in device arrays. Once you make most options loadable as kernel
modules, you have achieved much of the goal of "building" a kernel
without source because you don't need to build one in the first
place. If the next WC CD came out with a minimal generic kernel
(that was enough to get console & disk working) and everything
else as lkms, then I would most likely _never_ build a kernel
because my development work is done in user-space (except for
few simple lkms which I can't configure properly 'cause of the
way the system is designed. Sigh).

I wonder what percentage of FreeBSD users/hackers actually do
kernel development? And of those that don't, what percentage
configure their kernels with exactly those options that they
currently *need* rather than throwing in a few that they *might*
need?

> People might suddenly get the feeling that
> there's now also the kitchen-sink included. :)

The kitchen-sink -- that'd be an lkm wouldn't it?! Nice to have the
feeling that you could load it if you needed it, eh?

> And, if being faced
> with a compile-time vs. run-time decision, the latter usually actually
> _costs_ run-time.  So the kernel won't be only more bloated, but also
> slower.

For DEBUG and DIAGNOSTIC, yes. For what other options is there _inline_
(and therefore _costly_) code? No doubt there are a few, but are there
so many combinations of these options that you can't build a few
typical modules for those who don't want to have to build them. Looking
at some of the kernel source, I'd say that sys/net/if_ethersubr.c would
be one with the most options, but much of that is just switch-case
entries (which take space but don't cost speed). Those who want that
configured with *exactly* their specified options can build it
themselves.

Does FreeBSD *really* have to be a system that only nurds play with? 8-)

[blows dust of old Motorola system] Now, how do I boot this SysV thingy?
Sigh. It still works, damn!

8-)

> 
> -- 
> cheers, J"org
> 
> joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
> Never trust an operating system you don't have sources    for. ;-)
                                                        / \
                                                      available         8-)
Regards,

-- 
John Birrell                                CIMlogic Pty Ltd
jb@cimlogic.com.au; jb@netbsd.org           119 Cecil Street
Ph  +61  3 9690 6900                        South Melbourne Vic 3205
Fax +61  3 9690 6650                        Australia
Mob +61 18  353  137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701040051.LAA28752>