Re: src/sys/vfs

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

On Mon, Jul 16, 2012 at 01:57:17AM +0100, Mindaugas Rasiukevicius wrote:
 > > As part of future namei work (and also, likely, any nfsv4 work that
 > > gets done) I'm going to be splitting a number of filesystem-related
 > > functions into their system-call level and vfs-level parts. The
 > > primary aim of this is to unify the cut & paste versions of the
 > > vfs-level parts in nfsd with the mainline ones. It is also a step
 > > toward having better internal interfaces. All this has been discussed
 > > before and I don't think it's controversial.
 > 
 > Can you provide a small example of a split i.e. how exactly the current
 > code would change?

Haven't I done this already?

anyway, the idea is to change the structure from

   sys_rename -------------.
   sys_posix_rename ---------> do_sys_rename --> VOP_RENAME
   compat_yoyodyne_rename -'                  /
                              nfsrv_rename -'

(where most of nfsrv_rename is copypasted from do_sys_rename) to

   sys_rename -------------.
   sys_posix_rename ---------> do_sys_rename --> vfs_rename -> VOP_RENAME
   compat_yoyodyne_rename -'                 /
                              nfsrv_rename -'

Or are you looking for an actual patch? If so, sorry, I don't have one
yet.

 > > I don't have a timeframe for this and I certainly don't expect to do
 > > part (2) before -6 is released. However, if people are going to object
 > > to the idea of the reorg, or bikeshed over the name, I'd like to
 > > thrash it out now so it's settled by the time I'm ready to start
 > > throwing code around.
 > 
 > Please create a branch for this work.  Otherwise, it will be the same
 > as with quota changes which were practically unreviewable.

Nonsense. The problem with the quota changes was that they were large.
You may recall that before committing the main batch of stuff I posted
both all the diffs individually and a single combined diff spanning
all of it; both were too large to review without quite a bit of
dedication.

Creating CVS branches does not help with this sort of thing; it just
makes development slower. It also makes it less likely that the
changes will get tested before the final branch merge, at which point
if something breaks it's far more difficult to figure out what caused
it.

CVS branches are even less helpful for intermittent incremental
changes at fairly long intervals, which is how this stuff is likely to
get done.

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