[systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles
brueckner at redhat.com
Mon Feb 3 06:07:04 PST 2014
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 "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.
> 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
> 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
> - 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
> Which of course doesn't exist and confuses systemd
> 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
> 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?
More information about the systemd-devel