Separate console from starting tty #1600
Conversation
1. Convert VT_CONSWINDOW to e.g. 4 (4th terminal) 2. ...but always login on 0 with chatter going to e.g. 4 1. boot_mute=YES in /boot/loader.conf
Semi-noteworthy: this was an artifact of when the logic of switching to the`VT_OVERRIDE_STARTING_VT` was built into the operation of this function. That seemed a bit presumptuous and hopefully handling it via `SYSINIT` is less jarring
|
Don't we have a sysctl for this? Edit: I thought we did. We have A colleague also reported this can be achieved via device.hints. |
|
@concussious I would have thought that something like this should certainly be configurable through |
|
So I like this concept. However, I have some problems with the implementation. A kernel config option likely isn't the best way to do this. But it also brings up a much bigger issue. There's no way to set the console in any meaningfully useful way that's universal. If I want a serial console there's several different parameters I might set in the boot loader that will result in the boot loader telling the kernel, through a variable that could be overloaded but is obscure, how to do that. There's similar ways for video console. But there's no really good, universal way to specify a specific console to use. There's several serial ports available, sometimes multiple screens or video devices or in this instance, a particular sub-device of the main screen. So, the standard feedback I'd normally give on this is 'make it a sysctl / tuneable using this or that method' would make the situation worse. It would add another weird knob on the side to configure things that may or may not interact well with the other weird knobs we have. This is an interesting idea (I'd never do it on my systems, but I can see how others might want to w/o going the full splash screen approach), but it points out a bigger picture problem. Put another way, is there some variable that we can set in the boot loader that would cut through the mess and tell the kernel exactly what device(s) to use for its console? Is there a good syntax for this? Are there ways we can have good "DWIM" defaults that take into account things like the EFI ConIn variable, the SPCR table, the DBG2 table and whatever else and do it in a space efficient way? Can we unify some of the "purpose built" things for communicating other attributes of the console that we currently do in an ad-hoc manner? Is there some way to build this "new thing" without having to have all the "old things" converted over instantly? What's a good, thoughtful, extensible design that would allow us to break free from the bitfield interface we inherited from 386BSD 30+ years ago? |
No description provided.