I Looked at the latest IDE preview, and have heavy reservations.
We really should NOT have PCI chipset-tuning code in the kernel
UNLESS it is required to boot Linux (very unlikely).
Anything that is not required to boot, can probably be done
much better after booting, by use of a user-mode program
such as hdparm or a new "chipset-tuner" program.
The reasons for this are convincing:
-- the kernel is in non-pageable memory,
and therefore must be kept as small as possible
(and Linus absolutely *hates* unnecessary bloat).
-- new chipsets are released every few months,
whereas the kernel is released every few YEARS,
so it is impossible for the kernel to keep up.
-- a user-mode program can be much more clever
and have a fancier user-interface than kernel stuff.
The idea of the present IDE driver design was to implement enough
generic support (such as safe /proc/ide/*/config updates) functions
to allow user-mode programs to be developed for PCI chipset tuning.
There is little need or justification for placing direct chipset
tuning functions (for PCI) into the stock kernel. It just adds bloat
and discourages development of better user-mode utilities.
I think the PCI chipset-tuning stuff belongs in a user-mode program.
Older chipsets have some stuff in the kernel because they are harder
to support in a generic fashion than the current PCI interfaces.
Something to add to the kernel though, would be a drive "setting"
to allow DMA to be used on drives which failed the DMA autodetect at
boot.
This function is missing, due to my own shortsightedness.
Cheers.
-- mlord@pobox.com- 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/