The State Of Killing CONFIG_VT, Moving To User-Space

[Ericg]

And you totally missed the point. I don't need session management for a single purpose system that runs a specific script in Busybox from an initrd. But what I need is input and output, without having to do any magic or even writing a session manager just to see something.
Again, I am not talking about desktop systems, but there seem to be some developers that think Linux is all about desktop systems.
So I have to ask again, how will this affect me, when this becomes the standard and sometime in the future the old VTs become unmaintained or even removed?
It seems to me that there is a rush for "new" where it isn't necessary.

What do you use NOW to control it and to control init? (I havent worked with BusyBox myself so they may their own solution) SysV? For something that specialized I really doubt that anything the rest of the Linux ecosystem does will affect you unless it involves the kernel.

Yes, Config_VT will probably be unmaintained and removed eventually.. In which case you are left with kmscon, yes, but kmscon doesn't rely on systemd it just uses it if its available and configured to. Kmscon only REQUIRES udev and XKCB, both of which you should have even on a busybox system I would think. The KMSCON readme on github even states

If you want only a very basic kmscon program without any major dependencies, use:
$ ./configure --with-video=fbdev,drm2d --with-renderers= --with-fonts=unifont --disable-multi-seat --with-sessions=dummy,terminal

Again, I just don't see what you are complaining about. Something THAT specific is only gonna be really affected by kernel work (which, admittedly, the removal of VT IS kernel work, but see the text above)

Also if you talked to the devs about what is WRONG with the VT work... you'd know. Its a code-abortion as far as stability, maintainability and reliability-- everything that you SHOULDNT be able to use to describe in-kernel code

[Vim_User]

As far as whether you will be forced to use logind... no. If you actually read the article carefully one of the very first paragraphs states (and this has been re-iterated by other developers for similar situations) logind is becoming the defacto implementation of session management on the linux desktop. Does this mean you have to use logind? No. IF someone wants to come around and not use logind because they dont want to use systemd and they start to write their own session manager, thats fine. The only thing that will be required of them is to support the baseline logind API so that programs higher-up than the session manager dont have to actually worry about what the session manager IS. (No testing to see what session manager is in use and then using foo.bar.login(); and if using logind use logind.login(); its all just: login(); ).

And you totally missed the point. I don't need session management for a single purpose system that runs a specific script in Busybox from an initrd. But what I need is input and output, without having to do any magic or even writing a session manager just to see something.
Again, I am not talking about desktop systems, but there seem to be some developers that think Linux is all about desktop systems.
So I have to ask again, how will this affect me, when this becomes the standard and sometime in the future the old VTs become unmaintained or even removed?
It seems to me that there is a rush for "new" where it isn't necessary.

[c117152]

Yes, you're right. This exact question was asked and answered in the article comments (with the same XBMC example):

http://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/#comment-484

Well, that settles that I suppose Still, not too sure if it will be possible to XBMC on one screen while working on the other without a zero client... But I suppose that's probably sorted as well.

[Ericg]

i really have no clue but could it be this will end up like UMS vs KMS?
- lets get all the stuff out of the kernel...
10 years later:
- lets get it back into the kernel

why killing kernel console again.?
number one priority should be reliability (with no excuse) shouldnt it?

UMS has advantages, as Windows 7 showed -- a UMS video driver cant crash the kernel and can be automatically unloaded and reloaded with minimal difficulty which is great for user experience and stability. KMS has massive performance benefits because its in kernel space, at the risk of crashing the kernel.

Killing the kernel console is because kernelspace sucks and even the DRM guys want the VT out of the kernel. Also reliability isn't actually guaranteed... see my post on page 2 about how everything in userspace anyway.

[Ericg]

Is "Only one desktop session is active at a time!" means what I think it means ? So, I won't be able to have two window managers, and\or XBMC running at the same time? That's no good.
We've been seeing more and more only-in-gnome or only-in-unity programs and functionality recently (wifi anyone?). And, while it shouldn't be the case, as more and more functionality is moved away from the CLI and isn't integrated into some generic GUI program (and is rather made a gnome extension and the likes), we're becoming dependent on those window managers...

And I can't help think about the future here. There are mobile platforms coming along where a window manager might be the only difference between them and a linux desktop. A developer would definitely be interested in having one such session running concurrently to his own without extra hardware instead of some virtual machine. Writing a few lines, compiling, switching with ALTCTRLF7, running and testing stuff, switching back... It's a work flow worth keeping.

Wrong. He said "active" session-- means whatever one is on the screen. You can't run E17, Gnome, KDE, and XBMC all on separate VT's and have everything all rendering at the sametime or even really doing things at the same time.. (if I switch away from KDE i notice some things stop doing their work and basically think the computer is in sleep-mode). This is about the ONE that is on the screen.

[Ericg]

So what does that mean for people like me that like to implement single purpose systems, using Busybox running from an initrd? Do we have to use systemd, bloating and complicating our systems only to see output on the screen and have user input? What happens when the kernel panics before it is able to load one of those log modules? Will we ever know what happened?
I don't get why this developers try to kill off kernel components with only desktop systems in mind. Hello, welcome to reality, the largest install base of Linux is on Android devices, no systemd there, so no, systemd/logind is by far not the standard session handler.

As far as whether you will be forced to use logind... no. If you actually read the article carefully one of the very first paragraphs states (and this has been re-iterated by other developers for similar situations) logind is becoming the defacto implementation of session management on the linux desktop. Does this mean you have to use logind? No. IF someone wants to come around and not use logind because they dont want to use systemd and they start to write their own session manager, thats fine. The only thing that will be required of them is to support the baseline logind API so that programs higher-up than the session manager dont have to actually worry about what the session manager IS. (No testing to see what session manager is in use and then using foo.bar.login(); and if using logind use logind.login(); its all just: login(); )

Early level kernel panic? Serial Console. As ALWAYS, this has never changed since Linux's inception. Also like 99% of kernel config options... I see no reason why instead of as a module, the fblog and drmlog kernel pieces couldnt instead be built right into the kernel, ensuring that they are always active. initrd could at minimum load them-- and lets be honest, if your initrd is fscked, then youve got bigger problems and we're probably back to "A serial console is the only thing thats gonna help you"

Its killing off kernel components because they suck and kernelspace in general sucks and no one wants to code in kernel space if they can help it.

[Ericg]

The more I think about this, the more stupid it sounds.

Jesus christ its like the old Wayland vs X, systemd vs sysV FUD all over again...

Let me make this absolutely clear-- for you and EVERYONE else in this thread... EVERYTHING ABOUT THE VT IS ALREADY IN USERSPACE MINUS ALL THE BENEFITS OF USERSPACE.

If you're at KDE and you switch to a VT, that handoff is handled by X-- userspace (Switching from a VT back to X is handled by KMS)
Your login prompt at the VT-- userspace
Your bash/csh/zsh/sh shell-- userspace
All of your commands IN that shell-- userspace.

That first point up there, handled by X, is important-- if the entire computer is under extreme CPU and memory pressure, YOU ARE NOT GUARANTEED A VT SWITCH and if you DO get one you aren't guaranteed to be able to run kill -9 on whatever process is hogging things, or run reboot, or maybe not even run SYSRQ-- I know you SHOULD always be able to run the system rescue keycombos by apparently...there are even some situations where those can be blocked (yes they were enabled kernel config and all other necessary places. They just didnt work.)

The only way you can be "guaranteed" anything during an early kernel panic or other situation where you cant get to a VT to see output is to have a serial console plugged in next to you so you can see it all. That is the ONLY guaranteed way. EVERYTHING else is just pure and simple luck.

[TheCycoONE]

I think the keyword is "active". You might have two window manager sessions running, but presumably they're not both rendering to the same screen simultaneously? Because that seems to be the definition of "active" the article is using - it's not saying you can't run different stuff on different VTs, it's saying that only one of them is controlling the screen at once.

Yes, you're right. This exact question was asked and answered in the article comments (with the same XBMC example):

http://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/#comment-484

What you want is exactly the setup described in the article. You have to know that ?active? means ?in foreground?. You can have as many sessions as you want, but only one of them can be _active_. Or how do you think multiple sessions can be active? You cannot share a monitor between sessions at a time.
Switching between sessions will always be possible. So you can switch to XBMC, Weston, Xorg, Steam, console ? whenever you want. (btw., steam doesn?t really belong in that least. Session management is at a lower level than that, but according to your description it has a 1-to-1 mapping so we could see it as session).

The other concern people have is about the emergency use of VTs when their primary session locks up. That was addressed as well:

http://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/#comment-477

As Stephen already said, that is still possible. Having VT management in the kernel does allow reacting to keyboard events in interrupt handlers, however, you need at least a working bash to make use of an emergency console. And if bash can run, kmscon can run, too. In fact, the fbcon->fbdev->DRM layer is known to be fragile in those situations, so we could even end up with a more reliable emergency console.

I know Michael was trying to help by only providing the conclusion, but a lot of the important things were discussed in this article and weren't reiterated or summarized in the conclusion.

[Delgarde]

Is "Only one desktop session is active at a time!" means what I think it means ? So, I won't be able to have two window managers, and\or XBMC running at the same time? That's no good.

I think the keyword is "active". You might have two window manager sessions running, but presumably they're not both rendering to the same screen simultaneously? Because that seems to be the definition of "active" the article is using - it's not saying you can't run different stuff on different VTs, it's saying that only one of them is controlling the screen at once.

[M1kkko]

a mission to kill off CONFIG_VT, a.k.a. the VT console within the Linux kernel, and move it off to user-space.

The more I think about this, the more stupid it sounds.