> On Tue, Jan 22 2002, Andre Hedrick wrote:
> >
> > Linus, Jens,
> >
> > I need a function that performs the kmapping to return a pointer with all
> > the data needed for that transaction of the data phase, and will cross
> > pages correctly, and may cross more than 2 pages at a time in PIO.
> > I do not care how you do.
> >
> > char * majic_voodoo_mapping (
> > struct request *rq,
> > int nsect,
> > unsigned long *flags)
> > {
> > char * buffer_walk = ide_map_rq(rq, &flags);
> > nsect -= ide_rq_offset(rq);
> > do {
> > buffer_walk += get_some_more(rq, nsect);
> > } while (nsect)
> > return buffer_walk;
> > }
When I chatted w/ Anton, he suggested a char ** to allow page walking.
This is more in line for allowing a rq->bio_list walking.
Obviously I may not have the correct item but the idea should be clean.
> > This should solve all the problems in the data-phases and let the driver
> > run correctly. The result is on each "get_some_more" will all BLOCK/BIO to
> > return the partial competions of at least one page
> >
> > The function would behave like ide_end_request but only to adjust the
> > buffer in process, and make block/bio deal with munging it back to the top
> > layers on the partial completions, it will not stop the data IO process of
> > the ATOMIC command in process.
>
> That _is_ what ide_end_request is doing, it is not stopping any data I/O
> in progress. It is also atomic. What exactly do you think is missing?
If you are provided with an acceptable solution to make BLOCK/BIO more
flexable to the needs of the hardware, that is a possible answer and
should be acceptable, provided it does not violate other layers ?
> > Better yet, I will shut my PIEHOLE!
>
> Oh, that'll be the day. Lets just say I'm not running to get my
> calendar and the big fat marker. :-)
Don't worry, I will FedEX one to you so you will not have to search.
Cheers,
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
-
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/