>> if securelevel N does x, y, z; then we make new knobs for x, y, z.
>> these knobs are raise-only, like securelevel.  when you raise
>> securelevel, you get all its [effects] -- so the changes don't hurt
>> any existing configurations/uses.
> I hope folks don't take this wrong, but I see this as potentially
> opening a can of very nasty worms (of the fishing kind).  If we did
> such a thing, we would have to test against not only
> kern.securelevel, but the knob for x, y or z.

That's not how I read it.

Rather, I read it as having knobs for x, y, and z in the kernel;
additionally, kern.securelevel, a set-only variable, would, when set,
raise the knobs for x, y, and z.  There would be no single kernel
variable corresponding to kern.securelevel; it would not exist in any
form that could be checked against.

If we want to continue to support reading kern.securelevel, the read
routine for it would have to take the minimum of all the relevant
variables.  I don't see that as a big deal.

Of course, I could be misunderstanding.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B