Re: direct-to-BIO for O_DIRECT

[Andrew Morton <akpm@zip.com.au>]

Douglas Gilbert wrote:
> 
> Ingo Oeser wrote:
> 
> >On Sun, Jul 07, 2002 at 08:19:33PM -0700, Andrew Morton wrote:
> > > Question is: what do we want to do with this sucker?  These are the
> > > remaining users of kiovecs:
> > >
> > >       drivers/md/lvm-snap.c
> > >       drivers/media/video/video-buf.c
> > >       drivers/mtd/devices/blkmtd.c
> > >       drivers/scsi/sg.c
> > >
> > > the video and mtd drivers seems to be fairly easy to de-kiobufize.
> > > I'm aware of one proprietary driver which uses kiobufs.  XFS uses
> > > kiobufs a little bit - just to map the pages.
> >
> > It would be nice if we could just map a set of user pages to a scatterlist.
> 
> After disabling kiobufs in sg I would like such a drop
> in replacement.

Ben had lightweight sg structures called `kvecs' and `kveclets'. And
library functions to map pages into them.  And code to attach them
to BIOs.  So we'll be looking at getting that happening.

The other common requirement (used in several places in the kernel,
and in LVM2) is the ability to perform bulk I/O against a blockdev - simply
read and write a chunk of disk into a list of kernel pages.  So we'll need a
library function for that.   And the O_DIRECT/raw implementation can be bent
around to use those things.

> > Developers of mass transfer devices (video grabbers, dsp devices, sg and
> > many others) would just LOVE you for this ;-)
> 
> Agreed. Tape devices could be added to your list.
> Large page support will make for very efficient zero
> copy IO.

Haven't thought about large pages.  We don't seem to have an implementation of
them yet, and I'm not sure how the DMA mapping API would get along with
them.

-