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).
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. Nor is it necessary, as a program could always increase the verbosity of its SIGINFO responses if it had been less than some small number of seconds since the last SIGINFO it received; or it could have a command line option for verbosity level. Besides, it's really a matter of having a signal that if not caught does nothing tied to a terminal keystroke (as a nonviolent alternative to VINTR/SIGINT) that makes it interesting; absent the keystroke connection, one has to go to another window and apply kill or pkill, which is tedious. SIGINFO would give three control characters (not counting job control) that each had different behavior for the associated signal if it was not caught: kill, kill+core, or harmless. As long as one has one of each, one can (as I previously described) find some other way of overloading the meaning if the program chooses to catch it; so I don't see any more need for a 2nd SIGINFO-like signal than I do for a 2nd SIGQUIT-like signal. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
