A Run Down Of VT Switching On Linux

[Rallos Zek]

Making the console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possibile, This could be an essential part of GNOME 3!

[Vim_User]

Right now that maintenance is on the kernel developers. Moving it outside of the kernel means less maintenance for them, and more maintenance for the userland maintainers. The sum of maintenance stays exactly the same.

No, it does not. Now you have exactly one point where this software has to be maintained, the kernel. If you split that software out you multiply the burden of maintenance, because now every developer of projects using this software stack has to do the maintenance. Assume that only 100 projects use the kernel in this way you still have 100 times more maintenance.

[curaga]

Right now that maintenance is on the kernel developers. Moving it outside of the kernel means less maintenance for them, and more maintenance for the userland maintainers. The sum of maintenance stays exactly the same.

You're disregarding the system creator's maintenance as free - it is not. The kernel is a single package to maintain, if a daemon was needed additionally, it would be more total maintenance, as each system creator would need to make sure the versions are compatible, and that the daemon and kernel work together.

It's a safeguard against programs hogging resources, including input. There is no cleaner way of doing that, and the overhead is minimal, logind should just relay the input further if it doesn't include a preset keystroke.

I already presented the alternative, revoke(), which does not require an additional layer like that. What is unclean in it?

[GreatEmerald]

Yes there is, added maintenance for dispatcher and terminal. Like I said before, the number of independent software modules to maintain doubles with this approach.

Right now that maintenance is on the kernel developers. Moving it outside of the kernel means less maintenance for them, and more maintenance for the userland maintainers. The sum of maintenance stays exactly the same.

I may have gotten confused; if we're still talking about the input handling of logind, it's quite certainly an additional layer. It doesn't replace anything, it still uses the kernel's input devices underneath; but it also multiplexes them to its own virtual devices (the additional layer).

This is not separating problems cleanly to me.

It's a safeguard against programs hogging resources, including input. There is no cleaner way of doing that, and the overhead is minimal, logind should just relay the input further if it doesn't include a preset keystroke.

[curaga]

That's certainly not the definition of a layer, especially if it is not about adding a layer, but replacing a big one by several smaller ones.

And no, separating problems cleanly does not necessarily make the whole more complicated (at least according to widespread design practices).

I may have gotten confused; if we're still talking about the input handling of logind, it's quite certainly an additional layer. It doesn't replace anything, it still uses the kernel's input devices underneath; but it also multiplexes them to its own virtual devices (the additional layer).

This is not separating problems cleanly to me.

[Vim_User]

I'm not talking about an init system, I'm talking about the init process (PID 1). Like I said, there is no difference between having Bash as PID 1 and having a dispatcher, that spawns a terminal with bash, as PID 1.

Yes there is, added maintenance for dispatcher and terminal. Like I said before, the number of independent software modules to maintain doubles with this approach.

[GreatEmerald]

No, I don't. The init= parameter tells the kernel which process to run as PID 1, nothing more, nothing less. In this case it is Bash, there is no init system at all in use.

I'm not talking about an init system, I'm talking about the init process (PID 1). Like I said, there is no difference between having Bash as PID 1 and having a dispatcher, that spawns a terminal with bash, as PID 1.

[Vim_User]

Aha, so you are using an init after all.

No, I don't. The init= parameter tells the kernel which process to run as PID 1, nothing more, nothing less. In this case it is Bash, there is no init system at all in use.

[erendorn]

Every additional layer by the very definition increases complexity.

That's certainly not the definition of a layer, especially if it is not about adding a layer, but replacing a big one by several smaller ones.

And no, separating problems cleanly does not necessarily make the whole more complicated (at least according to widespread design practices).

[GreatEmerald]

The kernel can do that fine. Make the test, launch your system with the kernel parameter init=/bin/bash.

Aha, so you are using an init after all. Bash itself gets launched, but it doesn't matter. If instead of bash itself, you launch a dispatcher that spawns a terminal and bash for you, then you end up with the exact same thing you have right now. The only difference is that now the terminal is in kernelspace, and after that it will be in userspace.