RD> I'm not arguing that that is not the case, in fact I know this is
RD> absolutely true. I am concerned that it remain true. Khimenko Victor and
RD> Yoann Vandoorselaere seem to be arguing that it should not be.
Linus should NOT include random patches floating enough. Linus is good
maintainer: he says "no" often enough :-) And when he says "yes" it means
that he undertood why it's needed good enough and will accept amount of crap
in new patch.
>> Why not try to make your code 'prettier' and then resubmit it? No sense
>> yelling at others for saying they don't like the way it looks. If it
>> works well, fix the looks so that it is 1) neat 2) maintainable.
>>
>> -mb
RD> If it were my code, and there were an obvious way to achieve the
RD> functionality and meet those objectives, I would do so.
RD> It's not my code but I think the functionality Mingo created is
RD> worthwhile.
In short terms - yes. In long terms... I doubt it. And things worthwhile
in short terms live as outside patches (like Solar Designer patch or
bigphysarea patch and so on) till either
a) it's clear that functionality is needed badly enough in long terms and
cost is low enough to include thing in kernel
or
b) patch is abandoned.
RD> I don't have the knowledge of the kernel internals, the time, a
RD> machine I can boot 200 times a day and do kernel profiling on, etc, to
RD> develope code with equivalent functionality that is "prettier", "neat",
RD> and "maintainable".
RD> In all likelihood my idea of pretty, neat, and maintainable would differ
RD> from yours, and Linus, and without a doubt Khimenko Victor and Yoann
RD> Vandoorselaere.
It it'll be different from my and/or Yoann's idea about pretty, neat and
maintainabile thing it'll be Ok. But if it'll be different from Linus idea
about pretty, neat and maintainable thing then you'll be forced to do it
other way (or try to convinience Linus that your creation is in fact pretty,
neat and maintainable even if Linus thinks it's ugly and unacceptable on
first glance).
RD> Personally, in terms of asthetics; I think Kernighan and Ritchie had the
RD> right idea in their original implimentation of C. I really rather dislike what
RD> GNU and ANSI has done to it. It's become too full of fluff and too abstracted
RD> from the machine. But again that's just me.
RD> Given a choice between pretty or functional, I tend to opt for the latter.
And this mean you CAN NOT be maintainer for OS. It's BAD thing for such person.
RD> But that's just me. I think the user community doesn't care what it looks
RD> like, they just want it to work, they want and need the functionality.
Yeah. And that's why "user community" was unable to create OS like linux
while Linus was able to do so.
RD> I understand that maintainability is important to preserving functionality;
RD> I'm a little at a loss as to how additional schedualing points significantly
RD> impacts maintainability.
You can not reshdule at random place in kernel. You'll hit locks, broke drivers
expectations and so on. So EACH AND EVERY point of reshedulling add potential
deadlock. And thus EACH AND EVERY point of resheduling must be tracked and
it must be proved and resheduing at that point is safe. Even more: each change
in kernel must be done in a way which is NOT adding deadlocks. And thus EACH
AND EVERY point of reshduling add noticiable load on maintainers. Do you
understood no why Linus thinks it's wrong way ?
-
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/