lkml.org 
[lkml]   [2002]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Calculating kernel logical address ..
    Daniel Phillips wrote:
    >
    > On Monday 09 September 2002 20:13, Jesse Barnes wrote:
    > > On Mon, Sep 09, 2002 at 02:00:35PM -0400, Richard B. Johnson wrote:
    > > > Well I just read Documentation/DMA-mapping.txt as advised by David
    > > > and it seems as though it will no longer be possible to do what
    > > > many programmers have been wanting to do, to wit:
    > > >
    > > > (1) In user-code, allocate a buffer.
    > > > (2) Lock that buffer into memory.
    > > > (3) Call some driver that DMAs data to/from that buffer.
    > >
    > > It looks drivers/media/video/video-buf.c uses alloc_kiovec() and
    > > map_user_kiobuf() to do it. And I think Ben LaHaise was talking about
    > > removing these functions and creating some other, lightweight
    > > interface for the same purpose?
    >
    > Hopefully. My understanding is that kio is obsoleted by bio and aio,
    > anyone want to confirm/deny this?

    Mumble, mutter, dunno.

    There are two sides to kiobufs: they can be used as a front-end to get_user_pages (video-buf.c, Imran's application and at least one
    proprietary mpeg streaming driver of which I am aware). And they
    can be used as a container for direct IO to a block device (mtdblk.c
    and LVM1).

    Nobody seems to have come forth to implement a thought-out scatter/gather,
    map-user-pages library infrastructure so I'd be a bit reluctant to
    break stuff without offering a replacement.

    We need a general-purpose "read or write these pages to this blockdev"
    library function. For mtdblk, LVM1/LVM2 and probably swapper_space.
    With that we can remove the block IO stuff from kiovecs. And convert
    the other drivers to use get_user_pages() directly into an ad-hoc private
    page array. Those things would allow kiovecs/kiobufs to be retired.

    I guess we need to get more motivated about this, before some large
    piece of infrastructure (EVMS/LVM2) lands in the tree using ll_rw_kiovec.

    This:

    generic_direct_IO(int rw, struct inode *inode, const struct iovec *iov,
    loff_t offset, unsigned long nr_segs, get_blocks_t get_blocks)

    is getting close to what we need. But it is synchronous, and too
    heavyweight for swap I/O.
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:28    [W:3.367 / U:0.640 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site