linux-ipsec: to be or not to be, that is the config question Doing some internal fiddling with the way the kernel code gets built, I
ran into a problem we've encountered occasionally in the past -- the code
currently won't compile with the debugging option off. That should be an
easy fix for Richard, but it got me wondering. The following are some
tentative thoughts, subject to reconsideration, offered for comment.
Given that we now have klipsdebug to turn debugging on and off, is there
really a good reason to have a compile-time option for taking it out?
Unless there is a significant overhead for having it in but turned off --
I haven't gone and dug through the code for details -- I say this should
be dispensed with. Having debugging facilities available is a Good Thing
even in production code (and this isn't production code yet!), provided
that the overhead they impose is small. We should not be taking them out
without good reason.
Also, the fewer compile-time options we have, the fewer different ways we
have to compile the thing to test them all. (Which is, of course, the
reason why this problem crept in again -- for some reason we seldom have
cause to compile with debugging out...)
This line of reasoning can be carried further. Is there really a good
reason for having configuration options for each and every transform? An
option which should always be enabled is just useless clutter. I suppose
that a specialized application might want to custom-build a minimal binary
with only the bits and pieces expected to be wanted (or expected to conform
to Ruritania's cryptography laws). How likely is this to be a requirement?
We should think seriously about eliminating any configuration option that
nobody in his right mind is going to want to exercise. Providing more
options than necessary just makes everyone's life harder.
Henry Spencer
henry@spsystems.net
(henry@zoo.toronto.edu)
Received on Mon Jun 22 00:29:53 1998
This archive was generated by hypermail 2.1.8
: Wed Aug 23 2006 - 12:59:22 EDT
|