New guy here, but it strikes me that the only likely reason not to have
it (assuming you have IP networking) is the resource burden.

Actually, the same can be said to be true of a *lot* of things.  Like
the 8 gazillion PCI, PCMCIA, etc. device drivers.

There seems to be some work towards LKM to assist in this.  I think more
work needs to be done there.  Then questions like this one can go away,
because they will become moot.

LKM needs, I think, to reasonably support:

    1) pretty much any target driver should be an LKM

    2) it should be possible to have a really really tiny kernel, with
only an MFS in it containing LKMs for other devices needed to mount /
and /usr.

    3) there needs to be better linkage between probing a bus and the
module info.  See for example Solaris' driver_aliases file.  (Of course
that means that NetBSD needs some standard way of naming devices based
on info available without the driver loaded -- e.g. PCI vendor/device ids.)

    3) then a lot of the various configs can consolidate, because you
don't need custom kernels for most cases.  with the right LKMs you can
meet any need, and still be as lean as you need to be.

    4) the few other kernel compile time options need to try hard to
become run-time options ala sysctl or somesuch.   (Or in the case of
hard limits, become dynamic tunables.)

So, are folks progressing on this?  Is help needed?  How can I help?

I think the idea of the MFS based /lkm is *key* for certain kinds of
applications (like embedded systems).  Maybe that is a place to start.

I also know that someone is working on a real kernel loader.  How is
that work progressing?  Any help wanted?

    -- Garrett

Robert Elz wrote:
> Back last November[*], Greg Troxel made a change (for i386, the
> same probably should have been, and by now, might have been,
> made for other architectures as well) along the lines of ...
>
>   | Add (empty) INSTALL.local, parallel to GENERIC.local.
>   | Change INSTALL kernels to include INSTALL.local instead of GENERIC.local.
>
>   | With this change, one can add IPSEC in GENERIC.local and still build a
>   | release, rather than having install kernels not fit on floppies.
>
> This message isn't about that change, which is fine - not even really
> asking why that change was needed (I understand that).
>
> What I'm asking is why that change happened to be needed?
>
> Or in other words, WTF isn't IPSEC enabled in GENERIC already???
>
> GENERIC kernels have all kinds of other much less useful cruft
> enabled in them (exactly what varies from arch to arch), but ISO
> is pretty common, as is NETATALK, and NS and CCITT (X.25) are there in
> more than just a couple or ports.   What is it about IPSEC that would cause
> it to get left disabled?  It has to be more useful than any of that
> other stuff these days (even NETATALK which is probably the most used
> of the obscure protocols).
>
> Note: I am not suggesting disabling any of those others for the ports
> that have them enabled, so no-one needs to reply and defend their
> favourite toy.
>
> But I would suggest that on all ports for which they work, IPSEC,
> IPSEC_ESP, and (if it works, without side effects -- I've never needed
> to use it) IPSEC_NAT_T, be enabled, and certainly that this be done for
> those ports (which includes i386) which have all of NS, ISO, CCITT and
> NETATALK enabled in GENERIC.
>
> If there is some good reason why this should not be done (ie: a good reason
> why NetBSD doesn't believe that IPSEC should be enabled in normal kernels)
> then it should be documented (most probably in ipsec(4)) so others can
> take that reason into account before enabling it for themselves.
>
> If the patent issue is enough to exclude NAT_T, that's fine, but that
> should not affect any of the others.   The reasoning can't be related to
> excluding encryption, or anything like that - there's tons of that in
> other parts of NetBSD already.   So, why not?
>
> kre
>
> [*] Last November's e-mail is where I'm up to in my NetBSD mailing list
> reading - I had been meaning to ask this question for some time, Greg's
> change (which most likely might never have happened had IPSEC been in
> GENERIC all the time) just provided the inspiration to actually ask it.
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191