tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: vfs-level naming issue



Hi,
On Aug,Monday 10 2009, at 6:08 PM, David Holland wrote:

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)


So if I understand it correctly do_sys_mkdir will only copy needed data to
kernel space and call another function at vfs level ? I thought that
do_sys_mkdir was meant as your vfs_mkdir. Why nfs can't call do_sys_mkdir ?


Regards

Adam.



Home | Main Index | Thread Index | Old Index