Anyone who is telling you this needs to do their homework. Go look at
StrongARM and get NDAed. They will offer your pricing which is more
attractive and offer you a part that has far lower power and power/MIPS
costs. I know what I'm talking about, go check it out, you'll be glad
you did. If you don't get the info you need, contact me privately and
I'll put you in touch with the right people.
: I don't claim to have all the answers. I have a number of ideas that
: I'd like to test. The main claim I make is that I don't think it's
: obvious which approach will be the best. At least I'm willing to code
: something and test it. That seems more constructive than persistently
: poo-pooing ideas
Richard, it isn't the ideas that are the problem, it's the premise behind
them. I want you to get a solution that makes you happy, I just don't want
it at the expense of the generic kernel. A few points to consider:
1) We don't know if there is a problem. You yourself have said that
you just think there might be a problem and you want to "fix" it.
That's cool, but given that you haven't defined what you are "fixing",
it's sort of hard to justify the changes. Removing cache misses in
a benchmark test case is a poor justification.
2) The whole soft-RT stuff. I'd be a lot more supportive of your efforts
if it sounded like you understood the tension between time sharing
and RT. Can you explain why RT is not typically found in time sharing
OS's, the goals of each design, why they conflict, etc. If you
understood all that (maybe you do, but it sure doesn't sound like it
from your postings) and /then/ proposed your changes and explained
how they actually made sense in spite of the time sharing/RT problem,
that would be far more warmly received. At least by me.
3) Linux/RT. I really wish that you would get your friends to use this.
If you need help with this, I'll beat on Viktor to help you. Did you
know there is a company which produes a Linux/RT CD? Have you tried
it? Have you worked as hard at solving your problems in that space as
you have worked on other approaches? If not, why not? Is Viktor being
unresponsive? We'll fix that. Is there some feature that you need in
the RT kernel that isn't there? Spec it, I'll find someone to do it.
It would be so nice if you looked at this solution space in depth.
It's a really elegant solution and keeps the RT stuff, that 99.99%
of the users will never use, out of the kernel. I'd really like you
to balance your proposed changes with the need - that's a tradition
in Linux, and it is a good one. The road of operating systems is
littered with carcasses of examples where people forgot that balance
and ended up with and OS that suited noone.
I'm serious about being willing to help you if you are willing to explore
other alternatives. I agree that the RT kernel that Viktor has isn't as
rich a programming environment as the generic kernel. So lets fix that.
Lets understand what it would take to solve your problem and beat on the
Linux/RT folks to be responsive to your needs. If we can't get them to
help you, then you have a really strong case for fixing your stuff in the
generic kernel. But please give them a chance first.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/