> kernel src under 1.2.1 is a bunch of files with two letter endings. What is
> the deal with those?

Hmmm. Don't know. I've always compiled -current kernels.

> Again, I'm trying to come to terms with the way netbsd handles kernels.
> The one other system that I compiled kernels was Linux. If you are familar
> with that, then you would know that using the generic kernal that got your
> system going was a big memory hog. You could choose a kernel release, get
> the src for it (which came with the cdrom) and then re-compile it not to
> fix anything, but to make it as lean as possible. That is what I'd like to
> do for my se/30 and 1.2.1.

I know what you're talking about here. However, on PC's running Linux
you have a universe of drivers and support stuff. Under NetBSD/Mac68k
this is less of a problem mostly because device support is only recently
beginning to pick up some pace (a year ago we didn't even support quadras!).

The easiest thing to do is to pick up the kernel source either via FTP
or SUP. Once you do that, go to the config file and turn on or off things
you want or don't want. If you really want to strip things down you can
comment out devices you may not have out of files.mac68k. All of that
can be found in sys/arch/mac68k/conf.

Sorry, no make menuconfig here. :-)

> I got the current src tree, but again, now I now that its 1.3alpha. What
> happens if I compile that on a 1.2.1 machine?

It may not compile because your make and config binaries may not be able
to grok the 1.3 files. That's easy to fix, just get the latest sources
for make and config and compile those.

Just a recommendation:
Unlike Linux where people usually shy away from the bleeding edge by a
minor version or so, NetBSD/mac68k is usually much more stable in it's
-current releases. This is because so much of the Mac is undocumented
and the more we uncover the more stable things become.

A good example of this is how much the serial driver has progressed since
1.2.1 or how more ethernet support has appeared for more machines. As
we uncover how more devices work we do more things "properly" rather than
hard-coding them so things that were sort of flaky in the past become
less so. All my work on intvid has paid off for folks trying to use
ethernet cards on AV's because I discovered how to shut off video
interrupts on the CIVIC chip.

Maybe by the time NetBSD hits 1.4 things will be in great shape and we'll
have 100% hardware support (ok, maybe we won't have the DSP's going in
the AV's but too bad :) then people can start pondering issues of whether
kernel 1.5.x is more stable than 1.6.x or whatever. For now I would suggest
sticking with a very current distribution.