Sorry it took me so long to reply, I was away on a trip to Germany for two days.
> Stuff I know I have left to worry about:
> o Andre - can you check there is nothing in your jumbo patches I
> should have (I dont want to put the UDMA/new timer stuff into a
> 2.0.x kernel). I couldnt see any easy way to separate the MHz
> computation from it.
Hmmm, well, the MHz computation is entirely contained in the calibration code
at the end of /arch/i386/kernel/time.c (with Jumbo-9 applied). Although the
routine is written is gas, it is entirely inocuous. So you could just add this
routine to a "standard" 2.0.35 and people would get the MHz detection thingy
without any of the other benefits of Jumbo-9 (UDMA, improved gettimeofday()).
That should be pretty easy to do, but I think it's easier if you just tell me
what you accept to put in 2.0.36 from Jumbo-9, and I'll work on a patch against
2.0.36ac6.
There are some routines that go in bugs.h which are pretty nice too.
I would just leave the rest for Jumbo-10, which will be against 2.0.36 final
(personally, I need UDMA _and_ a stable kernel).
I don't want to go back to an old debate, but I still think that:
1) since (U)DMA support is protected by a kernel config option which is set
to default to off (CONFIG_BLOCK_DEV_TRITON), and
2) since UDMA is intrinsically more secure than DMA mode 2, and
3) since all motherboards and EIDE hard disks shipped since Jan 1998 support
UDMA,
I still believe the UDMA code should go in a 2.0.x kernel. People that don't
know what it's for won't even turn it on, but a lot of people will find it's
nice to have this option in the "official" kernel.
Obviously you decide, you are the Boss. :-)
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