16 Dec
2010
16 Dec
'10
9:12 p.m.
Le Thu, 16 Dec 2010 20:01:46 +0100,
Dhaval Giani <dhaval.giani(a)gmail.com> a écrit :
On Thu, Dec 16, 2010 at 7:53 PM, Dominique Michel
<dominique.michel(a)vtxnet.ch> wrote:
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.
Le Wed, 15 Dec 2010 20:07:37 +0100,
Dhaval Giani <dhaval.giani(a)gmail.com> a écrit :
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.). 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. 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.
Ciao,
Dominique
Dhaval
--
"We have the heroes we deserve."