Re: RT patch acceptance

[Andrea Arcangeli]

On Tue, May 31, 2005 at 02:29:52PM -0400, Steven Rostedt wrote:
> Probably, what I was talking about is diamond hard, and Ingo's RT patch
> is metal hard.  PREEMPT is just wood hard and !PREEMPT is plastic hard*.
> Leaving MS Windows as feather hard ;-)

Yes, this is a nice way to expose it ;)

> believe that what the -RT patch is giving us, is something that can give
> the Linux kernel more that it can guarantee, but not everything. Which I
> think is a good thing (and keeps me employed :-)

;)

One thing we should be careful: if syscalls aren't needed in the app and
all the MMIO space can be mmapped by the device driver and the app can
run fully in userland and be invoked from irqs, then going with the
"diamond hard" is not more complicated than going with the weak
solutions. The "diamond hard" will work in userland too, and it won't be
substantially different from a soft-RT "metal hard" approach like
preempt-RT. So it'd be very bad if people would choose preempt-RT if
they could equally easily go with RTAI or other "diamond hard" solutions
that are order of magnitude simpler and safer.

> more for telecommunication and as others said, music.  Before I left

Those are certainly areas where linux kernel has to be involved, and in
turn the "diamond hard" isn't feasible anyway without huge efforts. So
for them I definitely agree preempt-RT scheduling irqs in userland is
ok.

> * OK, maybe still not as hard as what is mentioned, but I couldn't think
> of better terminology. I do stand by what I called diamond and what I
> called feather. ;-)

;)

> the OS didn't need to be tested the same, and as mentioned, the lack of
> terminology for this is the source of most problems, as is demonstrated
> on this thread!

As you said what I've always meant with hard-RT is the "diamond hard"
thing. After all in linux everything that called hard-RT (RTAI, RTLinux,
nanokernel) was "diamond hard" so far, preempt-RT is the first time in
linux where I see the word "hard-RT" combined with something not
"diamond hard".

thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/