Re: vfs-level naming issue

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

On Mon, Aug 10, 2009 at 07:42:38PM +0200, Adam Hamsik wrote:
>> 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 ?

It could, just as it could be rearchitected in any number of other
ways. There are a bunch of reasons this would be undesirable, though,
which more or less boil down to:

   (1) Syscall-level code and vfs-level code *can* be separate and
       therefore they *should* be, for modularity, comprehensibility,
       and long-term maintainability.

   (2) Whether a pointer is a pointer to user space or not should be a
       statically checkable property, and passing around uio_seg
       defeats this.

   (3) The system call argument marshalling code that calls copyin and
       friends (and conses up uios, and other things) can and should
       be automatically generated from (a perhaps beefed up version
       of) syscalls.master, instead of being maintained by hand.
       Getting there requires prying it apart from the other logic
       that it's currently freely mixed with.

   (4) The real purpose of do_sys_* is to handle the common logic for
       different emulations's versions of the same syscall, and
       different variants of/entry points for the same syscall (like
       posix_rename) -- this is a different mission from handling the
       common logic for user programs and in-kernel filesystem users
       like nfsd.

For any one function drawing these distinctions carefully probably
wouldn't be worthwhile, but if you line up all the vfs-level functions
that should exist (there are a couple dozen) it makes a significant
structural difference.

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