Re: RT patch acceptance

[Karim Yaghmour <karim@opersys.com>]

Bill Huey (hui) wrote:
> Paths entering back into userspace are simple like the use of read() to
> respond to events.

Sure, but like Andi said, general increased responsiveness is not exclusive
to PREEMPT_RT, and any effort to reduce latency is welcome.

> Sorry, the RT patch really doesn't effect general kernel development
> dramatically. It's just exploiting SMP work already in place to get data
> safety and the like. It does however kill all bogus points in the kernel
> that spin-waits for something to happen, which is a positive thing for the
> kernel in general since it indicated sloppy code. If anything it makes the
> kernel code cleaner.

But wasn't the same said about the existing preemption code? Yet, most
distros ship with it disabled and some developers still feel that there
are no added benefits. What's the use if everyone is shipping kernels
with the feature disabled? From a practical point of view, isn't it then
obvious that such features catter for a minority? Wouldn't it therefore
make sense to isolate such changes from the rest of the kernel in as
much as possible? From what I read in response elsewhere, it does indeed
seem that there are many who feel that the changes being suggested are
far too instrusive without any benefit for most Linux users. But again,
I'm just another noise-maker on this list. Reading the words of those
who actually maintain this stuff is the best indication for me as to
what the real-time-linux community can and cannot expect to get into
the kernel.

> This is last day of vacation, but it doesn't feel like it unfortunately :}

I'm sorry you feel this way ... you do have the choice of not responding.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546