Hi,
it’s been a long-standing tradition on Linux to have 6 started getty
processes, in tty1 to tty6. However this doesn’t correspond anymore to
the way we use our machines.
* I don’t think we need more than 2 of these. They are still
useful for servers or when some disaster happens in the GUI, but
who opens 6 console sessions nowadays?
* For desktop machines, the display manager starts on tty7, which
means there is a tty switch to display it. This causes a small
latency and can also create some bugs when you’re using a
graphical boot splash.
To make things worse, the latest GDM upstream version doesn’t include a
tty manager anymore. Each started X server will simply use the first
available VT. Red Hat can afford to do that because their gdm is started
by the inittab (which is really a bad idea, but well), but in Debian
this means it takes tty1, stomping on the getty that gets launched here
later.
So before we start adding hacks on top of the existing, maybe now is the
time to think about how we want to use our VTs.
1/ What should be on tty1? Ideally, we should have the display manager
here if it is started, and we should have a getty otherwise.
* Does upstart make things like dynamic allocation of VTs
possible?
* Otherwise, shouldn’t we replace the getty processes started by
init by a small daemon that can allocate them as we see fit?
In all cases, as long as some consoles are managed by /etc/inittab we
are kind of doomed.
2/ How do we prevent bad interaction between console VTs and graphical
VTs? (Of course this is closely related to question 1.)
Given how they are done now, there will always be some race conditions
in VT allocations without a tty manager. But as long as this code stays
in GDM (and KDM, for that matter), we will be stuck to static allocation
of pools of VTs prior to start anything. We can do better than that, but
this requires system-wide allocation of VTs that could be queried from
the display manager.
3/ Even if we find a perfect solution, what do we do with legacy display
managers? That includes GDM 2.20, which is bound to stay here for a
while since there are other regressions. To avoid patching all of them,
there should be a fallback mode where the DM can allocate what it wants
starting from tty7, as it is possible now.
It is, of course, possible to integrate a tty manager in the new GDM
codebase and just keep things as they are today, but before doing that,
I’d prefer to look for better solutions.
I’d appreciate if people with knowledge of the init system could explain
their ideas on the topic so that we can decide on a course of action.
Thanks,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=