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. 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? Does it include any/all listed explicitly on the kernel command line? 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. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: PGP signature
