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

[phoronix]

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

Back in August I wrote about systemd working to create a new user-space VT solution that could eventually succeed the Linux kernel's VT support. With the upcoming systemd 217 release, the terminal is present...

http://www.phoronix.com/vr.php?view=MTgwNzQ

[danieru]

Why?

Can someone tell me what is the impulse for this?

[smitty3268]

Can someone tell me what is the impulse for this?

CONFIG_VT is extremely complicated, and whenever someone tries to fix a bug they usually end up creating 2 new ones.

The idea is to get rid of it, while simultaneously bring in new features and things that weren't possible with the old system.

[Delgarde]

Can someone tell me what is the impulse for this?

Read some of the links to previous Phoronix articles for details, but the gist of it is that the console is a big piece of code which sits in the kernel, and which would (arguably) be pulled out to userspace. The reasons are essentially that a) a terminal emulator is a big complicated thing to be running inside the kernel, and b) because of the constraints of running inside the kernel, it's not a very good terminal emulator.

The flip side is of course that the console is a fairly important component when things go wrong, and having it built into the kernel takes away a potentially brittle integration point...

[Ericg]

The flip side is of course that the console is a fairly important component when things go wrong, and having it built into the kernel takes away a potentially brittle integration point...

To an extent, yes, but remember that the shell you are actually using to DO anything "when things go wrong" is in userspace. So there's no guarantee that you can actually login or even execute commands in said console.

[Delgarde]

To an extent, yes, but remember that the shell you are actually using to DO anything "when things go wrong" is in userspace. So there's no guarantee that you can actually login or even execute commands in said console.

Sure, and personally, I'm happy with the changes they're making. I just mentioned the "flip side" as context for why it's a little contentious.

[danieru]

CONFIG_VT is extremely complicated, and whenever someone tries to fix a bug they usually end up creating 2 new ones.

The idea is to get rid of it, while simultaneously bring in new features and things that weren't possible with the old system.

Read some of the links to previous Phoronix articles for details, but the gist of it is that the console is a big piece of code which sits in the kernel, and which would (arguably) be pulled out to userspace. The reasons are essentially that a) a terminal emulator is a big complicated thing to be running inside the kernel, and b) because of the constraints of running inside the kernel, it's not a very good terminal emulator.

The flip side is of course that the console is a fairly important component when things go wrong, and having it built into the kernel takes away a potentially brittle integration point...

Thanks

[edoantonioco]

good thing: this will probably will make things better related to the console daemon.
not a good thing: another thing under the control (and dependent) of systemd.
At least that's what I understood.

[mark45]

good thing: this will probably will make things better related to the console daemon.
not a good thing: another thing under the control (and dependent) of systemd.
At least that's what I understood.

systemd is the future and technically that's what the consoled should be spawned off. Deal with it.

[Paul-L]

good thing: this will probably will make things better related to the console daemon.
not a good thing: another thing under the control (and dependent) of systemd.
At least that's what I understood.

Correction. Is a good thing, that is under the control of a init system, seriously; I don't see any other point where it would make sense to put a user-accessible console subsystem other than when the kernel starts (the current) or when the user-space/init daemon setups most of the system, by that, it could be anywhere after init, but if I were to choose, I still prefer any init daemon, including systemd, managing it.