A Run Down Of VT Switching On Linux

[jrch2k8]

Current status: You can get a shell with kernel + shell.
Your proposed status: You need kernel + shell + several daemons and helper programs to get a shell.

How is that an improvement?

you are mixing some concepts here, VT is not needed to run shells but for session handling which translate in hardware level event routing before the shell process even start, read here https://dvdhrm.wordpress.com/2013/08...itching-works/

btw kmscon move this for compatibility to userspace "Kmscon is a userspace virtual console for Linux, using kernel mode-setting (KMS) for output. It is intended to replace the Linux kernel built-in terminal. It is multi-seat capable, supports internationalized keyboard input and UTF-8 terminal output. The input support is done via XKB (xkbcommon), thus making all keyboard layouts for the X.org graphical environment available for input." and here you have a nice guide for arch if you wanna test it https://wiki.archlinux.org/index.php/KMSCON

so it really like this

kernel+VT+shell <-- before
kernel+KMScon+shell <-- now

all other demons you point are not to replace VT but for implement a proper advanced system compositor which is completely unrelated to VT

hope it helps

[curaga]

It is an improvement. It's called modularity. By your logic, integrating the X server into the kernel is a good idea because then you don't need several daemons and helper programs to get a GUI!

Again, scale. A few million line monster has no place in kernel.

The other part is about making things worse. You can't make things worse for the X example since X never was in the kernel. But if you removed VTs, you would make things worse for many users.

[curaga]

you are mixing some concepts here, VT is not needed to run shells but for session handling

It is needed, seems you're not 100% clear either. You need a VT + a terminal emulator both to have a shell on your screen.

KMSCON apparently can replace both: http://dvdhrm.wordpress.com/2012/12/...-introduction/

If run in listen-mode, KMSCON can also replace virtual terminals.

..which is what this topic is about. VTs, not the terminal emulator, though they are both needed. And both should be in kernel, incidentally

[mrugiero]

And both should be in kernel, incidentally

Why is so? I've seen both of you asserting it should or shouldn't be in the kernel, and none of you gave any reason for such assertions.

Again, scale. A few million line monster has no place in kernel.

The other part is about making things worse. You can't make things worse for the X example since X never was in the kernel. But if you removed VTs, you would make things worse for many users.

Actually, there are some guys providing a (closed source) module for having an X server on the kernel. Weird as it sounds.

[Ericg]

..which is what this topic is about. VTs, not the terminal emulator, though they are both needed. And both should be in kernel, incidentally

Having a VT and terminal in the kernel is useless unless you also port $SHELL and /usr/bin/login to kernelspace as well, given that SWITCHING to the VT is completely worthless if you can't do anything with it.

[Teho]

Why is so? I've seen both of you asserting it should or shouldn't be in the kernel, and none of you gave any reason for such assertions.

David Herrmann wrote an article about deprecating CONFIG_VT a while back.

[jrch2k8]

It is needed, seems you're not 100% clear either. You need a VT + a terminal emulator both to have a shell on your screen.

KMSCON apparently can replace both: http://dvdhrm.wordpress.com/2012/12/...-introduction/

..which is what this topic is about. VTs, not the terminal emulator, though they are both needed. And both should be in kernel, incidentally

the fact terminal emulator uses VT dont make it dependant on VT, if you check in that salad of code for the graphic iotcls you will see VT does not require at an terminal emulator at all unless you clear that ioctl state and force the text mode ioctls and even so you don't the terminal emulator beside for the explicit use of typing/seeing text in the screen

neither should be in the kernel unless you still have multiline rs-232 hardware to handle thinclients text consoles that only run linux 1.0 kernels

[mrugiero]

David Herrmann wrote an article about deprecating CONFIG_VT a while back.

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.

[jrch2k8]

Why is so? I've seen both of you asserting it should or shouldn't be in the kernel, and none of you gave any reason for such assertions.

well VT originaly landed in the kernel because in those ages you normally got 1 powerful server and a series of dumb much cheaper screens that needed to access this powerful server consoles to be useful through multiline serial hardware[normally rs-232], that is why VT still handle the concepts of TTY btw.

so time passes and thinclients start to dissapear because smart hardware got cheap enough, so we now have 1 powerful PC per seat instead but how multitask in the text-only ambar monitors worlds? switching consoles and so Virtual Terminals concept was added to VT, up to here VT was already ugly but useful and was nice to keep those thinclients still working

so time passes again and suddenly a big revolution start:
* easy to handle IRQ based AT keyboard and serial line interfaces go to museum and suddenly input hardware get really complex to handle -- lots of hack to VT code to do something was not designed for
* Text era suddenly drop dead - graphics come to the door -- VT don't know what graphics are, so lots of ugly hacks to make it work with a serial terminal design
* long live the forgotten ancient XXGA cards, hail the new king programmable GPU -- after hack after hack still VT hate GPU's today
* Users got really picky, they want proper resources usage and clean secure transitions for sessions -- hack hack hack ugly hack but even the maintainer gived up trying, is just not possble

today VT is nothing more that a waste of compilation time and a freaking pain, especially since kmscon do the same thing and better totally backwards compatible using 1% of the VT kernel LoC in userspace without any ovbious performance hit[i use it on arch since a while] and is more secure and fexible

so why keep this dinosaur in the kernel? i leave it to you

[curaga]

Why is so? I've seen both of you asserting it should or shouldn't be in the kernel, and none of you gave any reason for such assertions.

I posted ealier why it's the logical place:

They have every reason to be in the kernel, which is why they are. The kernel manages the display, the kernel manages the input. It manages the processes that run on that VT. Now, can you make an argument, when given all that, that the combination of those three should also not be in the same 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.