Re: Question about the ide related ioctl's BLK* in 2.5.7-pre1 kernel

[Martin Dalecki]

Jens Axboe wrote:
> On Mon, Mar 18 2002, Martin Dalecki wrote:
> [BLKRAGET etc]
> 
>>BTW> It's quite propably right now, that I will just reintroduce them
>>myself and give them the semantics of the multi-write hardware settings,
>>just to fix the multi write PIO problem :-).
> 
> 
> What would that fix?
> 
> I've still got the multi-write fixes pending, out tomorrow I hope. Other
> stuff keeps getting in the way. I haven't forgotten :-)

I think that it would make the write operation atomic in respect
to the BIO chunk write order. Or please have a look at
the following piece of cr... code from ide-taskfile.c:

	/* (ks/hs): See task_mulin_intr */
	msect = drive->mult_count;
	nsect = rq->current_nr_sectors;
	if (nsect > msect)
		nsect = msect;

	pBuf = ide_map_rq(rq, &flags);
	DTF("Multiwrite: %p, nsect: %d , rq->current_nr_sectors: %ld\n",
		pBuf, nsect, rq->current_nr_sectors);
	drive->io_32bit = 0;
	taskfile_output_data(drive, pBuf, nsect * SECTOR_WORDS);
	ide_unmap_rq(rq, pBuf, &flags);
	drive->io_32bit = io_32bit;
	

in esp. the nsect versus msect games whould go away and
if we have current_nr_sectors > drive->mult_count, we
are not going to write everything in one operation as it stands...
The above just *feels* to me like something that should
be pushed one layer upwards, since the sematics it has fits
quite nicely into what the ioctl in question should be about.

Plase note that I'm just speculating and feels free to correct me
if I'm entierly mistaken for some reason.

Please note as well that this is more about extending then
about fixing.