Great. Then solve the problem after you _know_ there is a problem.
Several people have told you that they don't like your approach. That
should be enough for you to have to justify your changes with real
applications which have been proven to be hitting this problem. That
should be trivial, according to you, because you have repeatedly come
up with long arguments as to why it must be true. Fine. Show that it
is true before you tinker with the scheduler. It's too important
to be changed because you think there might be a problem. Don't you
agree?
: I also think it's a bit unfair to label people who agree with me
: as "pseudo-RT friends".
Come on Richard, you're just being defensive. You seem to represent
a set of people who don't want RT but they want some other thing which
you call "soft-RT". I, and others with more experience in this area,
question the validity of any sort of real time features in a multi user,
time sharing system. We happen to believe that the two disciplines are
mutually exclusive. I don't know what you want me to call your friends,
but they seem to like this strange thing you call "soft-RT". Since that
is not considered real time by _any_ textbook or _any_ credible published
paper, I'm feel completely justified in calling it "pseudo-RT". So you
have these friends, they like your ideas, your ideas are focussed on
pseudo-RT, so I called them your pseudo-RT friends. What's the problem?
: > If you want to hack the scheduler for your own needs, that's great,
: > have the big fun. But if you want to tinker with that part of the
: > system which effects every single user, then it would not seem
: > reasonable for you to provide some examples of people who want this
: > fixed? Fair enough?
:
: Ignoring the fact that my changes had a net benefit for the general
: case, what you ask is difficult for the reasons I've outlined above.
:
: The best I can do in response is ask that someone out there with a
: soft-RT Linux application steps forward if they're having timing
: problems and we can see if it's due to the scheduler.
Great, that's a perfectly reasonable thing to do. I'd like to exclude
from that set of people your friends, because you are clearly the technical
lead for your friends so their independence is clearly in question. I'd
like to know if there is someone else who can demonstrate a need for the
changes you want to make to the scheduler. If nothing else, maybe I'll
learn something.
-
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/