Re: cvs commit: src/sys/kern kern_shutdown.c vfs_bio.c src/sys/sys buf.h src/sys/vfs/gnu/ext2fs ext2_subr.c src/sys/vfs/ufs ffs_subr.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>     sys/kern             kern_shutdown.c vfs_bio.c 
:
:The change in kern_shutdown.c breaks the LINT build:

    Fixed!

    I am going through a major buffer cache cleanup, I'm sure more things
    like that will pop up.

    The biggest mess is related to vfs_busy_pages().  I am exploring ways
    on getting rid of it, perhaps by requiring that a buffer be instantiated
    to back any dirty (vnode backed) VM pages.  This is actually a fairly
    straightforward case since once you have such a page the system will
    want to flush it to disk at least once every 30 seconds anyhow.  But
    it would allow me to get rid of all the bogus_page junk in the kernel
    and greatly simplify the buffer cache code.

    This is the chain:

    * Move the I/O command out of the b_flags field and into its own b_cmd
      field

    * Get rid of b_xflags

    * Get rid of VOP_GETPAGES and VOP_PUTPAGES.  Implement a buffer
      acquisition VOP instead from which the pages can be extracted.
      These VOPs have been an eyesore forever and we need a buffer
      acquisition VOP for things like sendfile(), userland VFS, more
      optimally cached front end read() and write(), and so on and so forth.

    * Require that vnode-backed dirty VM pages have associated buffer
      cache buffer(s) (depending on overlap).  This issue only occurs
      when you mmap a file SHARED+RW.  I may also have to require that
      the filesystem block size be a multiple of the PAGE_SIZE for the
      file to be memory-mappable, for this to work cleanly, but I don't
      think that effects anything.

    * Get rid of vfs_busy_pages(), bogus_page, and friends.

    * Clean up b_resid and b_bcount, in particular 'fix' the filesystems to
      always get buffers on filesystem boundaries

    * Get rid of the VM page scanning code used to flush filesystem pages
      (since we now have a valid buffer cache buffer for such pages).

    Not necessarily in that order.

					-Matt