Garrett D'Amore wrote:

> I hope there aren't any of those folks.  I.e., if you can provide
> equivalent functionality (e.g. a template rc script that loads the
> sysctls so that the system behaves the same for given securelevels),
> then maybe we don't need to keep the old model around, at least not in
> the kernel.

Actually, the old model is not really kept, but merely emulated by
the new one. Choosing between "old model" and "new model" can be a
simple thing of changing the default listener code for the system
scope.

> Anything under 10k is negligible.  Anything over 100k is cause for
> concern.  There is a big gray area in the middle.  :-)  Basically, if it
> makes life much harder for systems with constrained boot media, then it
> is a problem.  10k should definitely be less than the threshold of pain,
> but other than that, I'm not sure there is an easy answer.

Okay, so, I don't have my branch sync'd to current, but for a -current
(of March 7th) elad-kernelauth GENERIC i386 kernel, the size I have
is 8668522 bytes. Newer kernel (as of today), also GENERIC, has the
size of 8658790 bytes. That's 9732 bytes difference.

The kauth(9) kernel still includes some of the old interfaces that
should be removed, and I expect the newer kernel to contain some new
code too, but the change is still rather small -- or so it seems.

> Big NFS and CVS usage would probably be an excellent way to test
> performance. Maybe also do some kind of database runs, I'm not sure.

I can get around doing some local/over-ssh CVS benchmarks; you're
welcome to give the code a try in an NFS/database environment. :)

> My gut is that the performance impact is likely not on the hottest code
> paths.   But system call overhead (esp open()) should probably be
> checked, because a lot of performance metrics seem to follow that result.

I expect some overhead. Not too much, but given we now have more code
than we used to to do the same things, we must acknowledge that there
will be some overhead. Like you said, I too don't expect the impact to
be all that critical...

-e.

-- 
Elad Efrat