[LAD] [Jack-Devel] JACK, cgroups and systemd
dominique.michel at vtxnet.ch
Sun Jan 12 16:25:04 UTC 2014
Le Mon, 13 Jan 2014 02:39:08 +1100 (EST),
"Patrick Shirkey" <pshirkey at boosthardware.com> a écrit :
> On Mon, January 13, 2014 2:28 am, Dominique Michel wrote:
> > Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
> > "Patrick Shirkey" <pshirkey at boosthardware.com> a écrit :
> >> On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote:
> >> > Recently, I experimented with Debian sid, which use systemd.
> >> > Systemd idea is nice, but its implementation is a catastrophe.
> >> > It is more than one year I am using the kernel cgroups on gentoo
> >> > to get rt scheduling with JACK, that without any trouble.
> >> >
> >> > On Debian, this is just impossible, because whatever I try,
> >> > systemd insist to put what it think is good to have into the rt
> >> > cgroup, which soon or later result in a complete system freeze
> >> > with even dead magic keys. After loosing my time a few days with
> >> > this, I removed Debian and installed gentoo instead.
> >> >
> >> > I found the reason here:
> >> > http://article.gmane.org/gmane.linux.kernel/1063354
> >> >
> >> > "Lennart Poettering:
> >> >
> >> > Well, this feature is... completely irrelevant for normal desktop
> >> > people.
> >> > ...
> >> > In fact, I just prepped a patch to systemd to move every service
> >> > and every user session into its own cgroup in the 'cpu'
> >> > hierarchy (in addition to the group it already creates in the
> >> > 'systemd' hierarchy)."
> >> >
> >> > Another completely idiotic stuff of this guy.
> >> >
> >> > The point of the cgroups is it is possible to setup them for
> >> > whatever use will be made with a computer, and this guy think he
> >> > have the insane and pretentious capability to decide for every
> >> > single user of the use they will made with their computers, and
> >> > he is suggesting users doing something else are abnormal. He
> >> > must be stopped!
> >> >
> >> That patch is over three years old. It seems like you have found a
> >> loophole in the logic that was used to justify it.
> >> Granted, it's annoying but it just means we have to find a better
> >> solution.
> >> Similar to Fon's main objection to jack-session being *not flexible
> >> enough*. We all knew it would cause problems for specific use cases
> >> but we still haven't found a perfect solution to enable the
> >> flexibility that Fons identified while also allowing people to get
> >> on with the task at hand. Hence we have the less flexible but still
> >> useful for most use cases version of jack session.
> > With the cgroups, that flexibility exist. One of the main point
> > of the cgroups is to be flexible enough to be setup for any possible
> > use case. But with a systemd system, that flexibility doesn't exist
> > any more, because the only possible "normal" use case permitted by
> > systemd is to run a GUI (as stated by the "normal" one in charge of
> > this mess).
> > It is more than 1 year I use the cgroups within an openrc system,
> > and you can do whatever you want with the cgroups. The same apply
> > for sysv init system.
> > What made me mad in that story, is not because it is a bug into
> > systemd which made a kernel function to misbehave, I know very well
> > that the only one that doesn't make bugs is the one that doesn't
> > make code, but this is the complete lack of consideration for other
> > needs than what he consider to be the needs of a "normal desktop
> > user". Which strongly suggest users with other needs are abnormal
> > users. Which in turn imply that person is a racist when he suggest
> > I am abnormal. And I am not the only one, systemd will break any
> > cgroup configuration for any other use case than to run a GUI.
> Well we also see similar issues with PA and JACK. The reasoning
> appears to be that the different camps are not really interested or
> motivated to scratch each others itches and no one is being paid to
> do the dirty work to make sure the corner cases are being polished.
> I am working on getting some official funding for the latter so this
> issue interests me from that perspective.
I can only hope you will succeed with that.
> It seems the days are over when people had the time or motivation to
> fix the tricky and annoying integration issues under there own steam.
I can understand this when some developers seam use their time to break
the kernel and other important functions. We get udev breakage of
firmware loading with some modules, the *kit story which will hopefully
end with its disappearance, and now systemd which have a catastrophic
implementation. And that's only the ones I am aware of.
> Patrick Shirkey
> Boost Hardware Ltd
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
More information about the Linux-audio-dev