Richard L. Hamilton wrote:
Insofar as the defaults for VSTATUS and NOKERNINFO could be controlled
via /kernel/drv/options.conf, I'd choose (3) (which any site could change
to (1) or (2) by simply modifying that file and rebooting, as with any change
to tty defaults). If (4) is preferred or it is at present too tedious to figure
out a good way to print the load and process info, I'd favor at least
reserving a NOKERNINFO flag for the possibility of future use, along with
explicitly ignoring whether or not it was set for now. That way, code that
wanted to control that feature would not have to be changed if it were later
implemented (call it both more nearly portable and forwards compatible).
Printing the info shouldn't be too hard, but the question is if this is
a desirable, clean feature we'd like to have. The whole notion of the
kernel printing info to the user's terminal is, well, dirty. Though
there certainly is some precedent, like the dreaded "NFS server not
responding" messages.
As for the NOKERNINFO flag: reserving it might not seem like a bad idea,
but then again, having a flag that doesn't do anything does seem to
violate the principle of least surprise. On the other hand, I know that
at least NetBSD (and presumably the other BSDs) define a kernel tunable
that switches off kernel info printing, so this behavior is not unheard of.
As to Roland's wanting a 2nd signal reserved, I'm not sure I see either need
or precedent for it, and even one SIGINFO will start to leave the SIGRT*
rather thin; two of them would really be pushing it, unless it's feasible to
increase the total number of signals.
I don't like the idea of having a 2nd reserved signal either. Let's not
make it more complicated than it should be.
About signals: adding SIGINFO would probably mean we have to bump the
total number of signals anyway. Currently, the number of RT signals is
8, and that seems to be the minimum (e.g. _POSIX_RTSIG_MAX is defined as
8). I'm not quite sure what the defined/expected values are here.
SIGRTMIN and SIGRTMAX are defined to be sysconf(2) values, so that's no
problem, but having the number of available realtime signals drop below
8 could be a problem. If someone knows what the standards say, speak
up.. I have not been able to find a conclusive answer on this.
Bumping the number of signals (MAXSIG) would have the effect of
increasing the size of user_t (as u_signal increases in size). This
should not affect any userspace applications, with the exceptions of old
ptrace users and libkvm users.
In either case, there would be a brandz flag day, as the translation
tables used for signals unfortunately use _SIGRT*.
- Frank
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
