Excerpts from Niels Mayer's message of 2010-11-24 07:55:46 +0100: > 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 I recommend reading the original discussion on lkml _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
