> For 2.0.x simply because its a change to a fundamental piece of code that
> works ok now (albeit no optimally)
I have mixed feelings on this issue. Usually, I too feel that once a
piece of code works, even in a non-optimal way, it is best to leave it
alone. Specially when it comes to stable kernels. I _only_ use stable
kernels. I just cannot cope with the unstable kernels in a production
environment, I _hate_ it when a new kernel breaks and leaves my machines
unusable. This happened with kernel 2.0.32 (as shipped e.g. with i386
RedHat 5.0) on all my 6x86MX machines, and prompted me to start my
time.c kernel hacking. My previous single line workaround is now found
in 2.0.35.
OTOH, I have proposed the Jumbo patch against 2.0.35 because, on the
whole, the patch extends the functionality of the 2.0.3x kernels with
very little new code. Most of the new code is in the new CPU detection
routines, and consequently does not affect kernel reliability or
performance: it just provides better information.
The largest chunk - the UDMA part of Jumbo - can even be thought of as a
security measure, specially now that a blacklist feature has been added.
Just as a reminder, UDMA has CRC checking, DMA mode 2 has not. UDMA, if
anything, is safer than both DMA mode 2 and PIO mode 4. Obviously, the
fact that it doubles performance makes it desirable, too. Originally,
this part of Jumbo was called udma-generic, and it actually *trimmed*
*down* the triton.c source and executable. Together with Andre Hedrick,
Michel Aubry and Brion Vibber, we have now added various chipsets and
controller cards, and the code grew accordingly. The source is now
around 6KB longer than the original, the added code being mostly driver
initialization code: Mark Lord had done a perfect job with the original
run-time code.
The changes to time.c *shorten* the do_fast_gettimeoffset() function,
and make it much simpler conceptually too. This is a case where simpler
is faster and better. Faster, because the resulting gettimeofday() runs
120% faster (I was previously told this was critical for e.g. Web server
performance). Better, because it solves a few shortcomings in the
previous code it improves upon. The MHz thingy is the icing on the cake,
because the routine calibrates the TSC, and in doing so, gives us a MHz
detection feature for the kernel which works with _any_ TSC capable CPU.
If we have the data, why not show it? The cost of the calibration is 50
ms, done once at boot time i.e. negligible. Precision is better than
0.01%.
Also, just about all the code in Jumbo is better documented than the
code it replaces. Trim out the doc and the comments in Jumbo, and there
is very little new code left. But this small amount of code enhances the
flexibility, security and performance of the kernels that I use daily.
Since I intend to continue using 2.0.x kernels for quite some time, it
seemed to me that these were worthwhile additions to the basic kernel
source distribution.
What else? Take a look at the code! :-)
Now, I agree 100% with Alan's basic position: go slowly with unfamiliar
code. I am pretty confident that Jumbo doesn't break anything on my
machines, and it has been tested on everything from 486's to dual PPro
boxes with 2.0.35 SMP kernels. But when it comes to stable kernels,
there can never be too much testing.
Alan is in a special position too, because he now works for RedHat. When
you have to keep an eye on a new GNU/Linux distribution (and RedHat
distribs are famous for their reliability), you have to be extra-careful
with foreign kernel code.
IMHO in the long term GNU/Linux distribution vendors will find Jumbo
*increases* the reliability of the kernel code. This was my original no.
1 worry when putting together the Jumbo patch, flexibility and
performance were lower priorities (in that order).
But going back to Trever's original question:
> My question is simple, have Linus, Dave, or Alan (or anyone who might
> get it accepted into 2.1.x (probably too late for that now)) given a
> reason why they don't like it, or why it hasn't been accepted?
The simple answer is: no.
> Please, don't let this cause a long thread. It very well can be an
> ultra short, nonflame war, answer.
OK.
Cheers,
-- Andrew D. Balsa andrebalsa@altern.org- 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.altern.org/andrebalsa/doc/lkml-faq.html