Messages in this thread | | | From | (Larry McVoy) | Subject | Re: 2.2.2: 2 thumbs up from lm | Date | Thu, 25 Feb 1999 16:42:15 -0800 |
| |
: Yes, but I've been doing most of my benchmarks on a PPro and plain : P5's. And some of the target machines they have in mind are lowly : 386's or 486's. 386 embedded systems are expensive enough, going to : 486 or beyond adds a lot to the cost.
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/
| |