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

Greg, Kay,

quoted

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