On Sun, 2019-01-20 at 01:21 +0000, Wookey wrote: > On 2019-01-19 20:11 +0000, Ben Hutchings wrote: > > On Sat, 2019-01-19 at 11:08 +0000, Steve McIntyre wrote: > > [...] > > > * add lots more console= options to the grub.cfg for arm64 (to cover > > > all the possibilities), then let d-i startup work out which devices > > > exist from /proc/cmdlinge and spawn d-i on each. > > [...] > > > > I think you should look in /proc/consoles, not /proc/cmdline. The > > format is documented in > > https://www.kernel.org/doc/Documentation/filesystems/proc.txt > > Interesting. > > Currently reopen-consoles does: > if d-i console not already recorded > set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 kernel > unless it's set to serial on a non-serial tty, in which case unset it > make list of 'enabled consoles' from 1st 260k of dmesg > if one matching device, then set as console > if still not found (only) one, set to last one in kernel command line args > if still not found one, default to /dev/console > record chosen console > fi > start d-i on recorded console. > > I'm not entirely convinced that all this logic is actually needed/optimum, > but I don't know the history of it. You can certainly remove anything that relates to old kernel versions. > How exactly does /proc/consoles fit into that? The docs say it is > "registered system consoles". Does that correspond to the same list of > 'enabled consoles' the above is currently fishing out of dmesg? /proc/consoles shows everything on the global console_drivers list. Every time a console is added to the list the kernel logs a message with the format "%sconsole [%s%d] enabled\n". So these should match, except that (1) it is also possible to unregister consoles, and reopen- consoles doesn't account for that (2) the kernel log might have rolled over so that reopen-console-linux doesn't see the messages. > Does it include any/all listed explicitly on the kernel command line? It's a bit more complicated than that. The kernel has a table of up to 8 "preferred" console devices, which can be specified on the kernel command, or through Device Tree or platform code, or by a hypervisor. The device specified last (which usually means the last console= argument on the command line) is the most preferred. If some preferred devices are specified, then console_drivers will include all the console devices that are preferred *and* have been found to exist, and the most preferred (if it exists) will be first. Otherwise, the kernel seems to enable the first console device found to exist. > My current code leaves all this alone and just records/uses all > enabled consoles on the command line, not just the last one, but > ideally we'd autodetect and/or hardcode all the sensible available > consoles and run on them. > > If 'read /proc/consoles (and check the devices exist)' does this, then > that sounds very sensible. Reading /proc/consoles is exactly what you should do. Ben. -- Ben Hutchings You can't have everything. Where would you put it?
Attachment:
signature.asc
Description: This is a digitally signed message part