http://lwn.net/SubscriberLink/415740/54028f24b103f4ff/ ............................... "Most outspoken - as he often is - is Lennart Poettering, who asserted that "Binding something like this to TTYs is just backwards"; he would rather see something which is based on sessions. And, he said, all of this could better be done in user space. Linus was, to put it politely, unimpressed, but Lennart came back with a few lines of bash scripting which achieves the same result as Mike's patch - with no kernel patching required at all. It turns out that working with control groups is not necessarily that hard." ................................ Have these people arguing against Lennart ever heard of GUI apps? And what exactly is the "TTY" of an application "in the cloud." And how exactly would keying off the tty be used in a paravirtualized kernel? For example, many GUI based programs run out of pty's by running subprocesses or networked subprocesses. This includes applications based on libexpect(3), Qt apps using QProcess, or emacs subprocesses. How would this silly kernel-bloating hack work with such programs? So IMHO, this is design based on the flawed logic of "If the only tool you have is a terminal emulator everything begins to look like a text based program" Lennart agrees: http://lwn.net/Articles/415756/ ............... "Well, this feature is pretty much interesting only for kernel hackers anyway. It is completely irrelevant for normal desktop people. Because a) normal users don't use many terminals anyway and that very seldom and b) if they do that they do not create gazillion of processes from one of the terminals and only very few in the other. Because only then this patch becomes relevant. Heck, the patch wouldn't even have any effect on my machine (and I am hacker), because I tend to run my builds from within emacs. And since emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own scheduling group." ..................... -- Niels http://nielsmayer.com _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
