Messages in this thread | | | Date | Mon, 16 Nov 1998 17:15:31 +0000 | From | Mark Lord <> | Subject | PCI timings in kernel??? |
| |
Andre,
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/
| |