Date: Sun, 5 Jan 1997 14:01:56 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: jb@cimlogic.com.au (John Birrell) Cc: current@freebsd.org Subject: Re: kernel w/o source? [MOD_DECL in lkm.h] Message-ID: <199701051901.OAA18285@skynet.ctr.columbia.edu> In-Reply-To: <199701040051.LAA28752@freebsd1.cimlogic.com.au> from "John Birrell" at Jan 4, 97 11:51:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, John Birrell had to walk into mine and say: > J Wunsch wrote: > > Define `universal'. > > Default? I dunno, the crystal ball was a little fuzzy. 8-) Mine's in the shop. Along with my time machine and perpetual motion generator. > > 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. The SunOS kernel is configured and linked much like this. The object-only distribution includes only a few small source files which usually contain arrays that you can hack either directly or with config file options. Mostly there are conf files for the SCSI system (st_conf, sd_conf, etc), plus the main device table generated by config, and in_proto.c for setting a few variables dealing with networking. Using this you can configure out certain bits and pieces that you don't need. Tunable bits for other code that's only supplied in object form are set of as external references to variables in the conf files; the initial values can be set just be recompiling the conf files and relinking. (Again, this is a bit like the Space.c stuff in SYSV.) Things get a little trickier when you consider things like BPF. With SunOS, you're allowed to configure NIT support out of the kernel (which is a good idea on heavily used shell systems; if someone breaks r00t on the system, they won't be able to run a packet scanner). In our case, part of configuring BPF into the system involves some conditional code that's present in _all_ of the network interface device drivers. This would have to change: the condition code would have to become unconditional, and we'd need a bpf_conf.c file that would stub out the BPF functions if 'pseudo-device bpfilter x' didn't appear in the config file. The SunOS config(8) program also does special things for you. All object files are stored in an OBJ directory, but /sys/<arch>/conf/files lists all the _source_ files needed to build the kernel. When invoked, config(8) checks all these files and if it can't find a particular source module, it creates the final Makefile with a reference to sys/<arch>/OBJ/foo.o instead. So if files specifies that I need sys/kern/uipc_socket.c but that file isn't in the source tree, config puts sys/i386/OBJ/uipc_socket.o on the Makefile instead. > 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). Enough to get a console and disk working? That's not as small a deal as you make it sound. You still have to have a bunch of drivers compiled in to support IDE, SCSI and floppy disks. SCSI in particular is a bear since there are so many different types of controllers. And with our current LKM system you can't make the drivers into modules since then you have a 'chicken and the egg' problem: you can't load the LKMs until you can mount your disk, but you can't mount your disk until you load your LKMs. (What about mounting an NFS rootfs. Then you need INET support, NFS client support and all the network drivers.) That said, what would make this problem (and probably some others) go away is a BIOS-based disk driver, but we've discussed this already and the problems involved in doing something like this haven't yet been solved. (Talked about to death, yes, but not solved.) Getting the kernel to switch to real mode to use the BIOS and then back again is tantamount to turning lead into gold, and nobody seems to be in a hurry to implement vm86 support. (Then again, I'm not even sure that vm86 mode alone is enough to do it.) > 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? I always keep the kernel source (and usually also the build directory) on the system in case I run into a bug and need to patch it quickly. I've had this happen a couple of times. That said, I'm sure that some people wouldn't mind having an 'object-mostly' kernel distribution in addition to the full source distribution. That way people who want to make quick driver changes and don't want to recompile the whole kernel can just load the object-mostly kernel tree and do a quick relink. (Those with 386 systems where compiling a complete kernel takes a couple of hours would like this too.) People who want the whole kernel source can load the usual ssys archive instead. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701051901.OAA18285>