Subject: Re: kernel & libkvm [was IIci success]
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: current-users
Date: 01/11/1996 16:48:13
>> But this is unlikely to ever be the case with the suggestion that
>> started all this, which was to put something in kernfs which was the
>> kernel as it appeared on-disk before boot.  I somehow doubt this
>> would ever go into sysctl.
> And, i doubt that it would ever go into kernfs (and hope not, as
> well).

> Think about what it would require to do this.

> You'd do it one of two ways:
> 	(1) keep some type of pointer (symlink, vnode reference,
> 	    whatever) around to the kernel,
> 	(2) keep a virgin copy of the whole kernel in core.

> Think about the completely nasty hacks that would be required to do
> _either_, and also realize that you can't even _do_ the former
> reliably (because the kernel may not exist on any disk you have
> access to!).

Well, if you can't do (1), then you can't do (2) either without
cooperation from the bootblocks.  Are there any ports left without
working NetBSD bootblocks?

(2) wouldn't be that bad, though.  From my friendly local NetBSD/sun3

	[Daily-Planet] 22> size /netbsd
	text    data    bss     dec     hex
	631924  29792   95784   757500  b8efc
	[Daily-Planet] 23> ls -l /netbsd
	-rwxr-xr-x  1 mouse      775910 Dec 20 06:55 /netbsd
	[Daily-Planet] 24>

The text segment perforce has to stay around anyway.  The bss segment
can be synthesized on-demand.  All that's really needed is a virgin
copy of everything neither text nor bss, which cannot be more than
143986 bytes in this case.

But it also doesn't have to stay in core any longer than necessary to
locate some swap space.  Even if the kernel isn't generally pageable,
kernfs could special-purpose allocate some swap area for this data and
then free up the physical pages containing the original copy.

>> Hm.  We now have the following situation.
>> "I'd like to use procfs for this utility, but mustn't because it's
>> only optional."
>> "I'd like to make procfs non-optional, but nothing uses it."
> Stuck without procfs is not a bad thing, in many peoples' opinions.
> Make the kernel pageable, and then i'll let you have that memory.
> 8-)

Okay, kernfs then.  (Is procfs really that much of a pig?  It certainly
isn't wrt compile-time stuff; "size procfs*.o" in a (sun3) kernel build
directory, totaled, is text=6784 data=844 bss=8.  There's code in
kern/kern_sig.c and kern/vfs_conf.c as well, but only tiny fragments.)

					der Mouse