On Thu, Dec 09, 2004 at 03:39:50PM -0500, Nathan J. Williams wrote:
> 
> It seems that the "hardened system" approach you discuss prefers
> everything to be wired down and as little as possible to be
> configurable at run-time.
> 
> However, the general trend of development is for increased runtime
> configurability and flexibility (reflecting, among other things, the
> larger variety and hot-swap ability of modern hardware and
> applications).
> 
> It's not obvious to me that it makes sense, or will continue to make
> sense, to try to accomodate both of these ideals in the same system.
> 
> I'm not really sure what conclusion to draw from this, but I think the
> general issue needs discussing. The continued proliferation of "make
> more flexible, but add an option somewhere to rigidize" changes is
> very unwieldly in implementation, documentation, and testing.
> 

I agree here which is why I think a sysctl option to tighten it down
is perfectly acceptable for those who don't want certain cloning type
devices to be able to instantiate infinite instances.

But...if that's there we don't also need to add in code to hardcode the
same thing at compile time. If we're gonna do that, then the logic would
assume we'd be doing that for all dynamic type variables done today via
sysctl and the movement has been away from that. A sysctl is "good enough"
as it can be controlled directly at startup time and then move security
level up to whatever point you want. You get the same effect and there's
less one-off code in the kernel to worry about.

James