vfs-level naming issue

[David Holland <dholland-tech%netbsd.org@localhost>]

What should vfs-level and fs-independent functions (that are not vnode
operations) be called?

In my own work on various things I've always called them vfs_*
(vfs_open, vfs_mkdir, etc.) but it's recently come to my attention
that this can be confusing for people who've grown up assuming that
VFS_* are fs-specific indirect calls into the file system.

I would just as soon go ahead with vfs_*, since to me it seems
clearest, and it's what I'm used to, and so on, but if anyone has
strong objections I'm open to something else. (But, what?)

The issue arises because there ought to be an API layer in between the
syscall layer and the vfs-level code, so that the vfs-level functions
can be called from inside the kernel without getting entangled in
syscall foo. This is most important for nfsd, which currently contains
a lot of cut-and-pasted copies of vfs code, but it also comes up in
other cases when something inside the kernel wants to do file
operations.

The rough organization I have in mind is (using mkdir as an example
because it's simple):

    sys_mkdir   {linux,svr4,etc}_sys_mkdir
        |        /
        |       /          (syscall-level)
    do_sys_mkdir
  __________|_____________________________
            |     nfsd
            |     /            (vfs-level)
         vfs_mkdir
  __________|_____________________________
            |
          VOP_MKDIR               (per-fs)


(Note that while it may not be entirely clear that all these entities
really need to exist independently for mkdir, in general they do.
Consider open, rename, stat...)

-- 
David A. Holland
dholland%netbsd.org@localhost