A Run Down Of VT Switching On Linux

[jrch2k8]

I posted ealier why it's the logical place:


If the same place manages input, output, and the processes, it's fully logical the same place should also handle the connection and disconnection of those input and output devices to those processes. Ie, the revoke() syscall and friends.

Currently the kernel lacks the capability to revoke access to input devices. The logind solution is to abstract input devices in user space, creating a needless layer. It would be much cleaner to simply add the capability to revoke that access directly.

the problem is this is no logical, the kernel is too low and too unflexible for this operations and like VT today any replacement will meet the same end, and the functionality required from a modern system compositor is way more complex that simply grant or revoke access through syscalls, we need event partitioning, we need ACL based event propagation, we need GPU partitioning-routing, we need multifocus sessions, we need remote event session routings, we need compositor's to be session aware, we need kernel subsystems to be acl controlled from sessions and properly partitioned and stuff that will come in the future.

some parts i agree should stay in the kernel [cgroups, render-nodes, etc] but the session management and compositor belong to userspace

[curaga]

the problem is this is no logical, the kernel is too low and too unflexible for this operations and like VT today any replacement will meet the same end, and the functionality required from a modern system compositor is way more complex that simply grant or revoke access through syscalls, we need event partitioning, we need ACL based event propagation, we need GPU partitioning-routing, we need multifocus sessions, we need remote event session routings, we need compositor's to be session aware, we need kernel subsystems to be acl controlled from sessions and properly partitioned and stuff that will come in the future.

some parts i agree should stay in the kernel [cgroups, render-nodes, etc] but the session management and compositor belong to userspace

Revoke() is already implemented on BSDs, and I believe on Solaris too. So these people disagree.

If you have very complex scenarios, you should be able to use such a complex userspace system compositor to handle them. But the kick is you shouldn't kill the simple functionality for the people who want it at the same time.

[jrch2k8]

Revoke() is already implemented on BSDs, and I believe on Solaris too. So these people disagree.

If you have very complex scenarios, you should be able to use such a complex userspace system compositor to handle them. But the kick is you shouldn't kill the simple functionality for the people who want it at the same time.

btw BSD and Solaris session management is as horrid or worse than linux

what i don't get from your point is what exactly you need from VT than kmscon can't offer? what you assume will get lost for you once VT is removed? because i can't really find anything that go slower or fail to run with kernel + kmscon on x86 or arm, i guess that is the point

[GreatEmerald]

This article only gives reasons why on user land it might be better, not a reason why "it doesn't belong in the kernel".
I haven't seen any reason why it belongs, either.

It's a terminal emulator in the kernel. Terminal emulators are UI, and all the other terminal emulators (which are also all better than linux-console) are in userland. The kernel handles drivers, it has no reason to go handling UI, or processes (that's the job of init). The fact that it's in the kernel also makes it inflexible, because as mentioned you're not going to merge font rendering libraries etc. into the kernel, which means that linux-console is going to be forever limited. That is also a problem, because distributions usually just use that, instead of normal, useful userland terminal emulators (otherwise there are conflicts, because the TTY system is not up to the task).

[Vim_User]

I have to ask again, if the VT code will be removed, will my single purpose systems be able to display text and handle keyboard input (no session management, no init daemon, no switching to other terminals, No X) without adding anything to my userland?
Or is this just about how we can make the desktop better with abandoning what made Linux great, the flexibility to run it anywhere in any form for any purpose?

[Teho]

I have to ask again, if the VT code will be removed...

It will never be removed because it's part of the kernel and removing it would break the userspace interfaces. Eventually you will be able to do CONFIG_VT=n but the VT suppot will still always remain in the kernel.

[GreatEmerald]

I have to ask again, if the VT code will be removed, will my single purpose systems be able to display text and handle keyboard input (no session management, no init daemon, no switching to other terminals, No X) without adding anything to my userland?
Or is this just about how we can make the desktop better with abandoning what made Linux great, the flexibility to run it anywhere in any form for any purpose?

Even if it was removed, what is stopping you from using a very minimal init that spawns a console for you from userland? It's no different from having that in the kernel, it's just more modular.

[Vim_User]

Even if it was removed, what is stopping you from using a very minimal init that spawns a console for you from userland? It's no different from having that in the kernel, it's just more modular.

What comes next, adding systemd in the mix? There are still tasks out there where init systems are not needed and bring absolutely no advantages (rather disadvantages, having more maintenance work and more parts that can be buggy), why should we change that?

[Teho]

...why should we change that?

The thing is that no one is chaging that. This is about providing a better experience for those that do use more full featured userspace. I don't see any reason to limit ourselves to the needs of small embedded systems either.

[Ericg]

What comes next, adding systemd in the mix? There are still tasks out there where init systems are not needed and bring absolutely no advantages (rather disadvantages, having more maintenance work and more parts that can be buggy), why should we change that?

This is, in some ways, about increasing modularity, Vim. Yes that increase in modularity means that certain things you used to be able to be assumed to available by default no matter what, may not be. Modularity is good, but yes it can come at some expense-- in this case a learning curve for 'the new way.'

I point you to xkcd: http://xkcd.com/1172/ Every change breaks someones workflow Instead of shouting from the heavens to "Make no more changes!" Just accept change as an inevitable part of life. Evolution teaches adapt or die... Take a lesson from it.