preliminary vfs stage 2 patch (not for the weak of heart)

Matthew Dillon dillon at
Fri Aug 13 23:55:21 PDT 2004

    The preliminary vfs stage 2 patch is ready.  This patch is NOT for the
    weak of heart because I've just barely tested it.  Don't run it if you
    aren't prepared to lose something!


    This patch does a couple of things. 

    First, it changes the per-filesystem vop_ops to a per-mount vop_ops,
    which will allow us to use the vop_ops structure to manage all sorts
    per-mount (future) features like cluster or other forms of cache 
    coherency, (kernel layer) journaling, the storing of real filesystem
    statistics, and so forth.

    Second, it requires that all VOP calls pass the vop_ops as the first
    argument and the dispatch is based on that instead of needing a vnode
    to be passed as the first argument and using the dispatch in the vnode.
    This will allow us to start passing a namecache structure instead of a
    directory vnode for namespace VOP's (like open/rename/delete/etc). 
    (However, I didn't want to rewrite all the VOP_*() calls immediately so
    the VOP_* macros add the required argument).

    Third, it removes all VCALL()'s, replacing them with wrapper calls.
    VCALLs were primarily used by null and union mounts to forward requests
    down through the layers.  This type of forwarding will require kernel
    intervention to deal with the messaging layer and so these are all now
    wrapper calls.

    Forth, all VOCALL()'s are restricted to vfs ops chaining only (the
    vnoperate stuff).  And I simplified the macro's arguments.

    Note that you have to blow away your kernel object hierarchy and then
    rebuild it to avoid make/make depend failures with a moved header file.
    (e.g. rm -rf /usr/obj/usr/src/sys/<KERNELNAME> before make buildkernel).

    Only serious developers should try this patch.  If you do try it, please
    try to exercise as many VFS's as posible (e.g. union, null mounts),
    though keep in mind that some VFSs have stability issues as a matter of
    course that are not related to this work.

					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>

More information about the Kernel mailing list