I started this discussion last week with an apparent bug in the new CFS.
As it turns out, it was not a bug, it was an feature, a (undocumented?)

feature.
In the world of embeded device and real time programming it is not a

hard job to compile the kernel right for the desired usage und fix the

startup script to use the desired policy.
Getting back the old behaviour would be nice and in my opinion the right

way, because the new one breaks with POSIX. But I have a working

solution and that is for me what matters.
By the way - RT means not hard real time. Hard-RT is a marketing phrase.

A given combination of OS and hardware must handle a event in a given

time. Thats all.
Thanks for the support.
Regards,

Stefani, the hard RT "real woman" programmer ;-)
Am Donnerstag, den 28.08.2008, 11:42 -0700 schrieb Linus Torvalds:

quoted text
>

> On Thu, 28 Aug 2008, Mark Hounschell wrote:

> >

> > More and more are wanting and now finding the Linux kernel to be more

> > RT capable. I seem to remember way back you saying it was one thing you didn't

> > really care much about one way or the other. Thats OK. But, you _are_ the man.

>

> The thing is, the reason I dislike RT is that so many people have so

> different understanding of what RT means.

>

> Quite frankly, I think that the people who are complaining (like you)

> think that RT means "hard realtime". You think about literally specialized

> devices.

>

> A lot of _other_ people think that RT means "good audio latency", where it

> really is a lot softer.

>

> And neither camp seems to ever admit that they are just a small camp, and

> that the other camp exists or is even valid.

>

> And I'm not really interested. Quite frankly, I suspect the "we want to

> run something like pulseaudio with RT priorities" camp is the more common

> one, and in that context I understand limiting SCHED_FIFO sounds perfectly

> understandable.

>

> As to your

>

> > "just to protect a few _supposedly_ bad programmers???"

>

> quite frankly, most programmers aren't "supposedly bad". And if you think

> that the hard-RT "real man" programmers aren't bad, I really have nothing

> to say.

>

> 		Linus

> 

--

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/