Fernando Lopez-Lezcano <[EMAIL PROTECTED]> writes: > Hmmm, I'm getting really confused, I thought that the realtime lsm was > the one that was in 'mm (maybe none of them are?). Finally I found the > followup article on lwn that mentioned this: > > http://lwn.net/Articles/121887/ > > "...The end result is that the rlimit patch has come back out of -mm..." > > Maybe it was put back again afterwards? (this was reported on February > 10). Hard to follow all that's happening...
Difficult and frustrating. The kernel developers have decided not to merge the realtime-lsm, after all. Instead, they propose an rlimits extension for granting per-user realtime scheduling privileges. This does (barely) meet our minimum needs. It is inferior to the realtime-lsm solution for several reasons I feel too tired and discouraged to repeat again here. (Those who care should look the discussion up in the LKML archives.) It all smells like NIH syndrome to me (Not Invented Here). Since their solution won't be available for end-users until all the shells and PAM modules have been updated and everyone has upgraded to new distributions, I'll continue supporting the SourceForge realtime-lsm package for another year or two, as long as we still need it. I came away dissatisfied with the whole experience. There are a number of very good Linux kernel developers, but they tend to get outshouted by a large crowd of arrogant fools. Trying to communicate user requirements to these people is a waste of time. They are much too "intelligent" to listen to lesser mortals. In my former operating system development career, I do not recall any other kernel development team so totally isolated from end-user requirements. Apparently, they rely on the major distribution vendors for all external requirements input. We audio developers have no standing in that process, whatsoever. -- joq "Never try to teach a pig to sing. It wastes your time and annoys the pig."
