Re: [uml-devel] /sys/class/tty/tty0/active?

[richard -r. w. <ric...@gm...>]

Greg, Kay,

>> Is that a problem for UML somehow?

The login on ttyX takes 30+ seconds.
This very ugly and mostly wrong hack makes the login fast again:
mount -o bind /sys/class/tty/console/ /sys/class/tty/tty0/

/sys/class/tty/console/active exists and contains "tty0"...

> In general, the "crippled" environments might not really the right
> thing too run full-blown user login managers like logind.
>
> The main systemd 'init' will not have any problems with that, but
> running logind might not really work out under UML.
>
> Depending how far full-OS support in UML should go, logind should
> either not run inside UML, or if, UML should provide the needed bits
> for in virtual consoles.

Any x86 distribution works fine in UML.
If this will be no longer true due to systemd then better no systemd developer
ever crosses my way. ;-)

> If it is not to be solved otherwise, maybe logind needs more
> VT-avoiding logic like this:
>  http://cgit.freedesktop.org/systemd/systemd/commit/?id=addedec48ba0ffc4472ef6d3b5a45c9d4239f1cd

Yeah, would make sense.
Many systems don't have CONFIG_VT set.

One good thing is that systemd seems to uncover a nasty bug in UML's
console driver.
A login on tty0 crashes UML.

UML's console driver (arch/um/drivers/line.c) implements tty_operations.
The crash happens because the tty subsystem calls the driver's close()
function and later
write_room() or chars_in_buffer().

write_room() and chars_in_buffer() fail badly because close() already
cleaned up the driver's private data...

Greg, is UML's assumption wrong that after closing the tty no call to
write_room() or chars_in_buffer() can happen?
I have no idea why systemd is able to trigger this, UML's console
driver is old and has always worked quite well.

-- 
Thanks,
//richard