Messages in this thread | | | Date | Mon, 18 Mar 2002 14:43:02 +0100 | From | Martin Dalecki <> | Subject | Re: Question about the ide related ioctl's BLK* in 2.5.7-pre1 kernel |
| |
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.
- 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/
| |