Sorry this took so long to get back to.

"Gordon W. Ross" <gwr@mc.com> wrote:
> Right.  The current implementation requires "option GENERIC" iff the
> swap config line uses generic.  (As you pointed out, swapgeneric.c
> should initialize the mountroot variable so it won't fault. 8-)
>
> Does this implementation prevent you from doing what you want?
> I'm not sure I understand what configuration you are trying for.

It doesn't actually prevent me from doing anything.  It was only
confusing for a bit.

> The current implementation assumes that you really mean it if you
> specify something other than generic, and will never change it.

Right.  But the reverse situation -- when I want generic swap -- will
lead to problems unless I define 'options GENERIC', which I shouldn't
have to do.  Or so it seems to me.

As I understand it, if I'm building a generic kernel -- that is, one
that will run on "any" machine (for some value of any) -- then I should
define 'options GENERIC.'  If I'm creating a kernel specifically for
the machine spatula, then I should define 'options SPATULA.'  This
allows me to have things in kernel files that are dependent on the
preprocessor define SPATULA.  I might have some non-standard interface
board plugged into that machine, for example.  This is derived from
Berkeley tradition as I understand it.

Aside from just that, should the swap config line really be dependent
on an 'options' declaration?  (And vice versa.)  That seems odd.

Basically, this is all something I wasn't expecting, and so it took me
a couple days of re-compiling kernels to discover the dependence.  No
real problem now that I know what's up, I suppose, but it does seem
that the dependency should be removed.

As Theo suggested, why not move the generic config code into autoconf.c,
so that it's always in the kernel?  The extra space taken up will be
less than a few kilobytes in any case, and it'll then allow both
generic- and specific-swap kernels, independent of 'options GENERIC.'

Anyway, enough on that for the moment.  Perhaps I'll write some code
to examplify my opinion, and present that for review.  For now, though,
I'm still working on getting this 3/80 to boot.  And that's dependent
on me getting my 3/60 set up appropriately.

While compiling a kernel for my 3/60, I discovered another oddity.  If
I *don't* include the KERNFS option in my kernel, I get the following
message right before "starting rpc daemons:"

Data modified on freelist: word 4 of object 0xe526c00 size 36 previous type free (0x8 != 0xdeadbeef)

Depending on other options included or omitted, the machine will 
continue seemingly unharmed or panic later on (dumping a bunch of
numbers that are pretty much meaningless to me, since I haven't
thrown symbols back in yet).  Since this is the same KERNFS code that
other ports use, I don't immediately blame that code.

I wonder what's blasting over the freelist.  For now, though, instead
of tracking it down, I've opted to compile KERNFS support into my
kernels.  I get a nice, happy machine this way.  I really should look
back into this one someday, though.  (Does anyone else feel like
trying to duplicate this problem?  I don't know what other dependencies
are lurking around to trigger it.)

Just trying to provide more data points,
- Geoff