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
signature.asc
Description: Ceci est une partie de message numériquement signée