Control groups, part 1: On the history of process grouping

Posted Jul 2, 2014 6:20 UTC (Wed) by smurf (subscriber, #17840)
In reply to: Control groups, part 1: On the history of process grouping by josh
Parent article: Control groups, part 1: On the history of process grouping

The PTY driver does that already, no need for CUSE.

You can build a kernel without VTs and use "screen" for multiplexing if you want to.

Control groups, part 1: On the history of process grouping

Posted Jul 2, 2014 16:31 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

Only if you use the built-in PTY driver, which is part of the TTY system. I'm suggesting moving the complex and fragile TTY layer out of the kernel into userspace.

Control groups, part 1: On the history of process grouping

Posted Jul 3, 2014 15:10 UTC (Thu) by jpfrancois (subscriber, #65948) [Link] (1 responses)

And how would that make the tty layer less fragile ?
How would serial port be handled ? How would the serial driver be accessed from the cuse driver ?

Control groups, part 1: On the history of process grouping

Posted Jul 3, 2014 20:57 UTC (Thu) by josh (subscriber, #17465) [Link]

It wouldn't necessarily make the TTY layer less fragile (although as a userspace framework it'd be easier to test and keep stable). It would, however, help make the kernel less fragile. TTY is one of the touchiest bits of the kernel, where what looks like a minor cleanup can break behavior that a 15-year-old version of emacs depends on.

The kernel could provide raw-mode-only serial ports (a pure bytestream only), and allow the userspace TTY framework to provide any additional "cooked" functionality of ttyS* or ttyUSB* on top of that, analogous to how the kernel would not need need to provide tty[1-9]*.

Control groups, part 1: On the history of process grouping

Posted Jul 2, 2014 17:06 UTC (Wed) by deepfire (guest, #26138) [Link]

How does your reply make sense in the context, where the OP suggests _replacing_ a kernel part with a userspace part?