--L6iaP+gRLNZHKoI4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 20, 2006 at 11:03:05AM -0500, Thor Lancelot Simon wrote:
> On Mon, Feb 20, 2006 at 07:50:22AM -0800, Garrett D'Amore wrote:
> > joerg@britannica.bec.de wrote:
> >=20
> > > But back to the original question -- this doesn't affect IPSec at all,
> > > since it can't be made a module without a lot of efforts in any case.
> > >  =20
> > true, perhaps.  but if so, then why?  it seems a lot of ipsec at least
> > could be -- e.g. encryption and hash routines, etc.
>=20
> Except that those routines are almost always in anyway.
>=20
> IPsec hooks in all over the network code -- it is anything _but_ a "bump
> in the stack" implementation.  That makes it useful for more than toy
> VPN applications (unlike many BITS implementations) but also means that
> it is extremely difficult to cleanly separate out into a module, _and_
> that just including it in the kernel causes a measurable decrease in
> forwarding performance.  Which is why it's not in the kernel by default.

This issue is one thing that I think Linux got right. Most features are=20
not binary but tertiary, with "Yes" (compile in), "No" (not at all), and=20
"Module." The latter adds all of the hooks you mention but does not add=20
the actual code. The hooks default to a do-nothing (or do extremely=20
little) behavior and only turn on when the module is present.

I think we could gain a lot by following a similar path. Some things just=
=20
can't totally drop in, provision had to have been made before hand.

Take care,

Bill

--L6iaP+gRLNZHKoI4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFD+2e9Wz+3JHUci9cRAqZ4AJ97zbh2YiR+7k0Tidf6Tcsp8Nly+QCfda21
5VT/0J2g46jno7suC9dfPvM=
=mxaD
-----END PGP SIGNATURE-----

--L6iaP+gRLNZHKoI4--