svn commit: r331298 - head/sys/dev/syscons

[Konstantin Belousov]

On Fri, Mar 23, 2018 at 01:21:43AM +1100, Bruce Evans wrote:
> I don't like having a whole task for this.  The whole thing is just a
> hack to work around some the upper layers of the tty driver and some
> lower layers not having any input [escape] sequences to control the
> kernel.  Only the syscons and vt lower layers have such sequences
> (where they are actually key combinations that are converted to control
> operations instead of to input [escape] sequences).  To work around for
> hardware ttys, the filter for kdb sequences is abused to implement a
> non-kdb sequence for rebooting.
> 
> The tty input methods could check for kernel-control sequences and safely
> signal init.  This is a bit too complicated for syscons and vt since they
> can more easily check for key combinations, but wouldhave to convert these
> to standard sequences to get the tty layer to do the same thing.  (They
> have many more kernel-control key combinations and the non-kdb one for
> rebooting is just a bug for them.)  This is a bit complicated for hardware
> tty drivers too -- some use the tty bulk-input method and this shouldn't
> check for sequences, but should reduce to bcopy().  Hoever, to detect the
> kdb sequences, these drivers han to check at a low level anyway.  They
> can be clever about this and only check for the console device[s] which are
> usually only used for for input at a low rate.
This is both complicated and mostly pointless. The task mechanism
provides the easy solution, and more, the task mechanism was
specifically designed to allow to schedule activities in the more
allowing context, from a more restrictive context. I have no intent to
start the self-inflicting activity to code the attempt to modify a lot
of drivers to do what can be done in 10 lines of code.

> Calling kern_reboot() from fast interrupt handlers is still invalid.
> It is quite likely to deadlock.  In particular, it should deadlock in
> when kern_reboot() prints messages to the console.  Most console drivers
> have races instead of deadlocks by dropping their lock[s] in their
> fast interrupt handler before calling the buggy alt escape function.
I agree that it is mostly invalid. If SCHEDULER_STOPPED() evaluates to
true, then the clean shutdown is not possible at all on modern hardware.
Most drivers are asynchronous, and even the hardware reboot command
management is async.

Similarly, if initproc is not yet initialized, it is silly to expect
clean shutdown to occur. I just keep the existing behavior for these
corner cases, perhaps it was added for some reasons and might sometime
work.