Re: [PATCH] tmpfs work update (was tmpfs initial work)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi Matt,
:
:Thank you for the precise response. It is a same strategy of previous porter.
:I thought it is a way to remove a dirty hack (vm object and anonymous
:object shares rb_memq)
:I'll play around implementing a buffer cache (or maybe, a page
:cache)...it is a most interesting
:part of this poring.
:
:Regarding to the old APIs, I try to migrate the code to follow your vm
:change first.
:
:thank you again,
:-Naoya

    Cool.  Using the buffer cache is actually pretty easy to do.
    You are already using vop_stdgetpages() and vop_stdputpages()
    so you don't have to worry about those functions.  In fact,
    those functions require a working buffer cache anyway so when
    you implement the buffer cache mmap() will magically start
    working properly.

    If you use a fixed buffer size (say 16K) then you can use the
    new API to control truncations and extensions.  Basically
    nvtruncbuf() and nvextendbuf().  NFS uses the new API now too
    so you have a working example you can use.

    Using the buffer cache is pretty easy.  Essentially
    you are implementing a buffering layer in vop_read() and
    vop_write() which directly maps the VM pages in the backing
    object into kernel memory via the buffer cache, allowing
    you to use uiomove() to copy data from user memory into
    the VM pages and vise-versa.  For reference material HAMMER
    has the easiest-to-follow code for vop_read/vop_write.  NFS
    is fairly easy to follow too.

    Apart from vop_read, vop_write, and dealing with ftruncate()
    (file extensions and truncations via vop_setattr), plus the
    implied file extension which occurs when a write() appends or
    extends a file via vop_write, you also need to deal with
    vop_strategy.

    vop_strategy is the function which in a normal filesystem is
    used to read data from the media into the buffer cache or write
    data from the buffer cache to the media.  The READ operations is
    going to be a NOP.  The WRITE operation will have to be coded to
    deal with redirtying the underlying VM pages.

    --

    In terms of associating swap space with the VM object, you don't
    have to worry about it until you get everything else working.
    Once you do if you want to take a stab at it what you would do
    is implement the reading from swap and writing to swap in
    vop_strategy().  READ would no longer be a NOP, and WRITE would
    write the data to swap space instead of redirtying the VM pages.

						-Matt