[systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles

[Hendrik Brueckner]

On Mon, Feb 03, 2014 at 02:44:43PM +0100, Hannes Reinecke wrote:
> On 01/31/2014 05:08 PM, Hendrik Brueckner wrote:
> > Ensure to start getty programs on all essential system consoles on Linux on
> > System z.  Add these essential devices to the list of virtualization_consoles
> > to always generate getty configurations.
> > 
> > For the sake of completion, the list of essential consoles is:
> > 
> >   /dev/sclp_line0 - Operating system messages applet (LPAR)
> >   /dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR)
> >   /dev/ttyS0 - Already handled by systemd (3215 console on z/VM)
> >   /dev/hvc0  - Already handled by systemd (IUCV HVC terminal on z/VM)
> > 
> > Depending on the environment, z/VM or LPAR, only a subset of these terminals
> > are available.
> > 
> > See also RH BZ 860158[1] "Cannot login via Operating System Console into RHEL7
> > instance installed on a LPAR".  This bugzilla actually blocks the installation
> > of Linux on System z instances in LPAR mode.
> > 
> Hehe.
> 
> Nice try, but sadly incomplete.
> 
> When switching to a real 3270 console (try 'conmode=3270' on the
> kernel command line) systemd isn't able to open a console, either.

You are right.  This change is incomplete regarding support for the 3270
terminals.

> Which opens up a can of worms:
> 
> - The S/390 3270 tty device is using a device node
>   /dev/3270/ttyX _and_ an offset '1' to the minor node.
>   So the first tty here is in fact /dev/3270/tty1

So this requires yet another entry to the systemd rules file to tag 3270
terminal devices.

> - systemd is using the 'active' sysfs attribute in
>   /sys/class/tty/console to figure out the active
>   console; for the 3270 console this contains the string
>   'tty32700'.
>   Which of course doesn't exist and confuses systemd
>   getty-generator.
> 
> The reason for the slightly weird string in 'active' is the way it's
> generated (check drivers/tty/tty_io.c:show_cons_active()):
> 	count += sprintf(buf + count, "%s%d%c",
> 			 cs[i]->name, cs[i]->index, i ? ' ':'\n');
> 
> where 'cs' is the _console_ structure, not the tty structure.
> So we're getting the _console_ name plus the _console_ index here.
> And the console name for the 3270 console is 'tty3270', with the
> index '0'.

>From the source code this simply states the name of the console device.  The
console device is not say *anything* about a potential associated terminal
device.  Console names (console= kernel parameter) are just identifiers.

> 
> Which raises the question: what exactly should be 'active' contain?
> The console name (which doesn't have any equivalent in sysfs), or
> the tty name (which has)?
> 
> And, more importantly, how is one supposed to _find_ the
> corresponding sysfs entry for the current 'active' attribute?

Perhaps it's time for a new sysfs attribute to display the associated terminal
device (if any).

> 
> From what I've seen most driver work by virtue of the happy accident
> that the console index equals the tty index.

This is just naming... you can also develop a console without any terminal
device involved.

> But that's not a requirement anywhere in the console code.
> Quite the contrary; tty drivers have the 'first_minor' entry
> to explicit request an offset other than '0'.
> 
> (And the console driver has an explict '->device' callback
> which allows the tty driver to return the correct index.
> Not that it's used here; would've been too easy).
> 
> So how to fix this?
> Update the driver to adhere to the (broken) current behaviour?
> Or modify 'active' to return the corrent tty name?

That's probably a good option but might break existing applications that rely
on what is in "active".  Alternatively add a new sysfs attribute to display
console's associated terminal devices.

... or don't look at the console at all and start getty's on those terminal
devices that are available.

> Or add a workaround to systemd?

Kind regards,
  Hendrik