Systemd 217 Will Introduce Its New "Consoled" User Console Daemon

[erendorn]

This whole VT thing confuses me. I've disabled all fancy VT stuff from the kernel. I only use the standard 80x25 console. I've disabled NLS, fonts, bootsplash, modesetting.. Isn't that the most basic thing on PC since the dawn of computing? How does it not work inside the kernel?

I think there's simply no reason to have it in the kernel. And doing stuff outside the kernel is much easier and cleaner, so should be done whenever possible. It's true for the most basic stuff, but it's even more relevant for the fancy stuff even if some people disable it.

[caligula]

I think there's simply no reason to have it in the kernel. And doing stuff outside the kernel is much easier and cleaner, so should be done whenever possible. It's true for the most basic stuff, but it's even more relevant for the fancy stuff even if some people disable it.

The thing I don't get is what is this 'it'? Imagine a headless server or a server with a simple vga display to show a login prompt in 80x25 text mode. AFAIK the 80x25 mode requires like 2 instructions to set video mode and one instruction per character to display something. What kind of kernel subsystem we are talking about? It's as simple as it gets.

[MoonMoon]

The thing I don't get is what is this 'it'? Imagine a headless server or a server with a simple vga display to show a login prompt in 80x25 text mode. AFAIK the 80x25 mode requires like 2 instructions to set video mode and one instruction per character to display something. What kind of kernel subsystem we are talking about? It's as simple as it gets.

If it is that simple, why is no developer willing to maintain it? Or why don't you just do it?

[caligula]

If it is that simple, why is no developer willing to maintain it? Or why don't you just do it?

Wtf man, I'm asking the question. I'm obviously stating that I have no idea what 'it' is in that previous message. Obviously it means I can't do it cause I don't even understand the issue. My observation is just that the console VT output is one of the most primitive things that has been part of kernel since day 1. I don't understand how it's so problematic and how systemd could fix it.

[erendorn]

Wtf man, I'm asking the question. I'm obviously stating that I have no idea what 'it' is in that previous message. Obviously it means I can't do it cause I don't even understand the issue. My observation is just that the console VT output is one of the most primitive things that has been part of kernel since day 1. I don't understand how it's so problematic and how systemd could fix it.

I started writing a post, but found out this message which explains quite well the issue:

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html

--- old post because, well, I already wrote it ---
There has been efforts to "kill" the kernel console since a few years now, you'll find the most documentation by searching about the KMSCON project.
Of interest are these two blog posts from its developer:

http://dvdhrm.wordpress.com/2012/08/12/killing-off-config_vt/

http://dvdhrm.wordpress.com/2012/08/11/kmscon-linux-kmsdrm-based-virtual-console/

Note that for this project, systemd is only used for the capabilities of logind, ie managing various users for convenient multi seat. The same could certainly be done with any implement of the logind scope.

Regarding consoled, it's actually the same developer, but a smaller, nothing fancy replacement for fallback when kernel console is disabled.
-----------------------------------------------

[erendorn]

Wtf man, I'm asking the question. I'm obviously stating that I have no idea what 'it' is in that previous message. Obviously it means I can't do it cause I don't even understand the issue. My observation is just that the console VT output is one of the most primitive things that has been part of kernel since day 1. I don't understand how it's so problematic and how systemd could fix it.

Another link, with the interesting bit
"[...] Both the terminal emulator itself and all the code to handle keyboard input and text or framebuffer console output (fbcon) we can get rid off, and replace with a more proper userspace counterpart."
So even for the most basic case, it seems that there is still quite a decent amount of code involved that can be moved to user space.

[RahulSundaram]

Wtf man, I'm asking the question. I'm obviously stating that I have no idea what 'it' is in that previous message. Obviously it means I can't do it cause I don't even understand the issue. My observation is just that the console VT output is one of the most primitive things that has been part of kernel since day 1. I don't understand how it's so problematic and how systemd could fix it.

Others have provided quite a few references but here are a set of quite necessary but poorly support things in Linux console at the moment

1) No consistent locale settings for keyboard mapping between Xorg/Wayland and the console.

2) Very poor support for those who don't read English

3) Accessibility for blind or users with poor eyesight

Everything necessary to fix these issues either has to moved into the kernel or the whole thing moved out. The latter happens to be the much easier of these two options.

[discordian]

The thing I don't get is what is this 'it'? Imagine a headless server or a server with a simple vga display to show a login prompt in 80x25 text mode. AFAIK the 80x25 mode requires like 2 instructions to set video mode and one instruction per character to display something. What kind of kernel subsystem we are talking about? It's as simple as it gets.

Terminal Input processing aint easy (= handling single characters, its not like you get a ready made string, you have to handle stuff like backspace on strings that span multiple lines), you have a standard set of encodings, this is a small glimpse: http://wiki.bash-hackers.org/scripting/terminalcodes
And a dozend dialects on top of that, even more headaches if you enter the non-ascii world. Language encodings shouldnt be in a kernel at all IMHO, if they are within strings (like filenames) the kernel should just pass them along.

If you for example look at bootloaders (U-boot) with minimal terminals you will find a host of issues shortly. I managed to store a couple of control codes in the environment variables, wasnt obvious until I did a hex-dump...

[jrch2k8]

But seccomp and that stuff is completely optional in the kernel. You surely know what you're talking about?

This whole VT thing confuses me. I've disabled all fancy VT stuff from the kernel. I only use the standard 80x25 console. I've disabled NLS, fonts, bootsplash, modesetting.. Isn't that the most basic thing on PC since the dawn of computing? How does it not work inside the kernel?

yes seccomp, audit, cgroups, selinux, RBACS, tomoyo, etc all are optional in the sense they are not required for software to works, hell even some kernel core functionality is optional this days.

The whole point of systemd(or the biggest at least) is security, so following that logic this optionals features get used to provide security but if you remove the optional security frameworks why would you want systemd??? is a lot easier to migrate the .service file parser to sysV and you are done.

So if you decide to use this security frameworks like systemd did you need to provide and adapt to the logic this frameworks requires(cgroups PID1 for example)

so, in resume all security features in the kernel are optional and systemd use them while sysV don't so far so good, now what is the problem then? you could ask. Well the problem is simple

a.) sysV depended on 2 dead unmaintained for years projects aka consolekit and udev
b.) CGroups new maintainer(as in kernel maintainer) gave a massive rewrite to the logic due to several exploitable defects(you can find out more in LKML) and make some requirements to userspace developers
c.) systemd developers took udev to maintain it and created logind to replace consolekit while all other init systems developers looked the other way and did nothing
d.) systemd was the only init system project that responded the call from CGroups maintainer, so ovbiously systemd is the only cgroups capable init system out there not because of tyranny but because no else even tried

So, as you probably are guessing right now once systemd took the job of handling cgroups properly all its dependency chain started to get rewritted to comply with the new security model, shit hitted the fan because other init systems want logind and udev to be generic and OS independant because they don't want the hassle of adding security to their own init systems but they neither want to fork or maintain consolekit(or alternatives) and udev(gentoo tried tho gudev but not sure if stays active) themselves, they want systemd developers to do it.Ofc systemd developers said hell no, you add security to your project and provide this set of interfaces so you can use then improved code of those dependencies.

So far no one even tried to do it and they spent most of their time crying in forums telling all kind of lies about systemd and of course the BSD whiping crowd joined them(no people jails is not anywhere similar to cgroups), the irony of the BSD crowd is that even if systemd devs please them and migrate all linux security infrastructure needed for systemd to X BSD, they will get inmediately rejected because they are not defined in the POSIX standard(no BSD zealot will ever allow anything that break their holy all powerful POSIX standard ever)

[jrch2k8]

Wtf man, I'm asking the question. I'm obviously stating that I have no idea what 'it' is in that previous message. Obviously it means I can't do it cause I don't even understand the issue. My observation is just that the console VT output is one of the most primitive things that has been part of kernel since day 1. I don't understand how it's so problematic and how systemd could fix it.

ok, Linux VT is not a console on itself(as a terminal window in the screen XbyX characters) that code lives in other place, VT handle console sessions(as old days multiseat TTY(as serial ports RS-232) thin clients sessions) and pretty much as you imagine the code is salad patched over the years to handle current hardware logic(not very nicely tho) and became basically unmaintenable and very hard to work with.

The work VT does today is basically the same as KMS/fences and logind could do(+ some new logic) but horribly horribly done, the reason they want to remove it is it cannot be improved further and is actually making security handling and isolation a hellish nightmare and is actually blocking many nice things to happen(like true multiseat - multiinput -multigpu support) because even try them will take years of rewrite in the VT code