Le Thu, 16 Dec 2010 20:01:46 +0100, Dhaval Giani <[email protected]> a écrit :
> On Thu, Dec 16, 2010 at 7:53 PM, Dominique Michel > <[email protected]> wrote: > > Le Wed, 15 Dec 2010 20:07:37 +0100, > > Dhaval Giani <[email protected]> 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. Ciao, Dominique > > Dhaval -- "We have the heroes we deserve." _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
