Re: Old -rt patches
From: John Sigler
Date: Tue Aug 07 2007 - 04:27:37 EST
Daniel Walker wrote:
John Sigler wrote:
Would anyone care to comment?
I'm not sure if this is the answer that you're looking for, but yes you
certainly will find fixed bug is older version of the tree.
I am not a kernel hacker, therefore I can only imagine how complex it is
to bring real-time to Linux. For some reason, I had come to believe that
the case of a single CPU without dynticks had been "solved" in the more
recent kernels (say 2.6.20), and that development had moved on, and was
now active in more "complex" areas like SMP/multi-core, dynticks, etc.
Perhaps I could also test a different strategy, such as xenomai?
http://www.xenomai.org/
If it's a kernel bug it's not going to matter if you use a xenomai skin
or not.. If you use some other real time layer that might fix it ..
*If* it is a bug in the -rt patch, then Adeos/Xenomai coupled with a
vanilla Linux kernel should not be affected by the same bug. Unless my
logic is broken somewhere.
you really need to test your app on a current version of the kernel ..
We as developers generally don't support out dated trees..
This is the part I don't understand. I work for a tiny company with
limited resources. It's infeasible for me to track every new kernel
release and upgrade every time. I need to pick a kernel version that has
the functionality we need, test it thoroughly with my app, and then
never touch that kernel again.
Unless I am mistaken, some people (like Thomas) have been deploying
systems based on PREEMPT_RT (or just -hrt) in indutrial settings for a
long time. (As far back as 2.6.15?) Obviously many bugs have been fixed
since then, which means that these versions contained many bugs.
How does one react when an important bug in found in a system that is
already in the field? Do they provide a way to upgrade the kernel (like
consumer-grade network routers)? Do they replace the complete system?
Regards.
-
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/