Messages in this thread | | | Date | Tue, 12 Feb 2002 13:57:01 +0100 | From | Vojtech Pavlik <> | Subject | Re: another IDE cleanup: kill duplicated code |
| |
On Tue, Feb 12, 2002 at 01:45:10PM +0100, Martin Dalecki wrote:
>>> The first does control an array of values, which doesn't make sense in >>> first place. I.e. changing it doesn't >>> change ANY behaviour of the kernel.
>> Actually HFS uses it ...
> Please note that the use in HFS is inappriopriate. It's supposed to > optimize the read throughput there, which is something that shouldn't > be done at the fs setup layer at all. The usage of read_ahead there > can be just removed and everything should be fine (modulo the fact > that in current state the HFS filesystem code is just non-working > obsolete code garbage anyway ;-).
Yes; I just commented on that it does change some behavior of the kernel.
>>> The second of them is trying to control a file-system level constant >>> inside the actual block device driver. This is a blatant violation of >>> the layering principle in software design, and should go as soon as >>> possible.
>> Yes. But still block device drivers allocate the array ...
> Well if we do: > > find ./ -name "*.c" -exec grep max_readahead /dev/null {} \; > > One can already easly see that apart from ide, md, and acorn drivers > this has been already abstracted away one level up at the block device > handling as well. My suspiction is that there is now already *double* > initialization of the sub-slices of this array there. Anyway ide > should be adapted here to the same way as it's done now for scsi. > > Will you look after this or should me? (I can't until afternoon, > becouse I'm at my "true live" job now and have other things to do...)
Am I understanding you correctly that we can just remove the max_readahead references in IDE (and possibly also md and acorn)?
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |