[LAD] [Jack-Devel] JACK and RT cgroups

Dominique Michel dominique.michel at vtxnet.ch
Thu Dec 16 20:12:52 UTC 2010

Le Thu, 16 Dec 2010 20:01:46 +0100,
Dhaval Giani <dhaval.giani at gmail.com> a écrit :

> On Thu, Dec 16, 2010 at 7:53 PM, Dominique Michel
> <dominique.michel at vtxnet.ch> wrote:
> > Le Wed, 15 Dec 2010 20:07:37 +0100,
> > Dhaval Giani <dhaval.giani at gmail.com> a écrit :
> >
> >> > Turn about again, and i suggest that the jack/RT implications as
> >> > part of "being fair to all, with no favourites' weren't given any
> >> > consideration, or you wouldn't be here now.
> >> >
> >>
> >> Someone made a noise, and so I knew about it. Not about jack being
> >> a favourite. If projectX would have an issue, and I would be
> >> informed, I would be equally willing to help them. I however would
> >> not be in a position to keep a look at all projects out there and
> >> what issues they would face if featureY came into existence.
> >>
> >> > I'm not throwing a tantrum, just staggered that something like
> >> > this could happen in the first place. It just seems so obvious,
> >> > as a logical process of feature construction, to consider wider
> >> > implications, as you wrote, for all users, including chaps that
> >> > use, and/or code for, jack/RT.
> >> >
> >>
> >> Considering the fact that its only JACK facing issues (or at least
> >> complaining), that too after two years of a feature being in
> >> existence and after about a year for the default cgroup being
> >> created, I think the decision was just fine.
> >
> > I am a non coding project administrator. My distro of choice is
> > gentoo, so I am able to configure, compile and install a kernel.
> >
> > As such, I think than the less you can make is to add a text into
> > the kernel help that address the fact that RT_GROUP_SCHED and
> > CGROUPS will break any rt enabled software without expropriated
> > setup, and that with a pointer to the documentation that will show
> > how to do such a setup.
> >
> I am still not seeing where RT_GROUP_SCHED and CGROUPS breaks any rt
> enabled software. As has been repeated on this thread countless number
> of times, there is *no* issue in the kernel. The issue is that by
> default the userspace tools create a default group (I still hold to
> the view that it is the right thing to do.).

What is the point to install a kernel feature without the corresponding
user space tools ? So, this is a kernel issue at the first place. And
this must be documented into the kernel help.

What is the point to install the user tools when its default
configuration will break existing applications ? So, the second place
to document it is into the user space tools, so that both casual users
and distribution makers can make the right choice and configuration.

> An application which uses
> rt privileges is *special*.
From a programmer view, yes. But from the user perspective, this is
just an application among other applications.

As project administrator, the documentation is one of my major
preoccupation. If anyone can understand it, I am happy. If not, I make
the needed changes it myself.

> Either,
> a) The application should make it much easier for the user to use this
> capability (by for example creating the appropriate cgroups and so
> on), so that it works out of the box or,
> b) Inform the user what he needs to do very clearly and have the user
> do the hard work.

Many rt aware software was existing long ago cgroup and libcgroup. So,
b) must be addressed at the first place : the cgroup kernel help
(for advanced casual users) and into licgroup documentation.

And also, distribution makers must be aware of their choices : by
enabling new features that can break existing ones, they must
understand that they have a hard work to do : make sure than their
packages will work with each other, or they will be loosing users.

> What is being repeated again and again that making a one line change
> to a configuration file is going to discourage new users. As I have
> mentioned again and again, this has been in there for a few months
> now,

Most of the good applications cgroup and libcgroup are breaking has
been into linux for years.

> and if it were such a big deal, there would have been tons of bug
> reports.

Wrong, users are not fools, and before reporting bugs, they done some
searching, or ask to some forum. Why do you thing they will issue
bug reports when it is only some good working software that is not
working anymore because of a miss-configured third party application ?

> Also, this problem is going to come up again once systemd
> comes into play. So it has to be fixed by the application as opposed
> to people coming about and complaining how Linux developers are
> totally against the jack community and are out to get them by making
> such changes.

Why do you want to force third party applications to adapt their code
to your software when it is possible to 1) get ride of your software,
2) configure your software in a why the user can use its favorite
application without problem ?

Or do you gave a secret agenda where you want to make 1) impossible for
every one and 2) impossible for normal users ?
> So, as has been done in the past in this thread, there are folks who
> have stepped up to the challenge, and there are patches already
> floating about. Instead of encouraging them, and supporting them (with
> reviews and the like), instead folks are coming, repeating this
> conspiracy theory.

In one hand you say that it is easy to configure the user tolls, in the
other hand, it is no documentation than a casual user can understand
and follow. It is not a conspiration theory but a prod by the act: you
are not willing to make your piece of software affordable for the
casual user, and it will make life harder for them, as well than for
the distribution makers.
> The only way to move forward is for rt applications to be aware that
> Linux is different, and if you want your application to work out of
> the box, some changes need to be made.

I agree with you, but the first change to make are to the documentation
of cgroup and its user tools. Again, why do you want to force to make
changes to their code when this is not needed.

> This is my last post on non-technical issues in this thread.

Do I need a special list ? the LAPA Linux Audio Project Administrator ?

Why do you not explain what will be the benefit for a casual linux
rt user of cgroup and libcgroup ? If you can do so and I find that it
can be useful for the applications I am managing, I can and certainly
will change my mind.

As project administrator, the project documentation is one of my main
concern. If I huge than anyone can understand it, I am happy. If not, I
make the needed changes myself.


> Dhaval

"We have the heroes we deserve."

More information about the Linux-audio-dev mailing list