Re: Decomposing vfs_subr.c

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

On Wed, Mar 23, 2011 at 10:07:42PM +0000, Mindaugas Rasiukevicius wrote:
 > > > > 
 > > > > - I think it should be vfs_vnode.c?
 > > > 
 > > > OK, unless somebody will come up with a better name.
 > > 
 > > Since AIUI from chat this is going to contain the vnode lifecycle and
 > > code and not e.g. stuff like vn_lock, I think I'd prefer vfs_vncache.c.
 > > But, vfs_vnode.c is definitely better than vfs_node.c.
 > 
 > vfs_vnode.c then.

surely you see that it will only contain a small part of the total
vnode-related code, so it shouldn't have a misleadingly general name.

(the existing vfs_cache.c should become vfs_namecache.c)

 > >  > Speaking of structural clean ups - I am thinking about moving vfs_*.c
 > >  > into a separate src/sys/vfs directory.  Given that clean code history
 > >  > of vfs_subr.c is already damaged (*cough*pooka*cough*) and decomposing
 > >  > will do more - it might be worth going all the way.
 > > 
 > > Well, forcibly moving vfs_lookup.c right now (or anytime in the near
 > > future) would be a bad idea, so let's not. After that stuff
 > > stabilizes, perhaps we can. Though I'd kind of prefer having real
 > > rename support before launching on major reorgs.
 > 
 > I would say better move early, so the history of your further changes will
 > be preserved.  Rather than you make changes, and then history gets cut.

No, I'd say it's a bad idea to do a move like this partway through a
major reorganization. It should wait until the reorg is complete and
stable, so the complete history *of the reorg* is in one place. (That
or it should have been done first; I would have been fine with it if
you'd suggested it then.)

I'm also still inclined to think we should avoid doing major reorgs
until we have proper rename support. Otherwise, where do you stop?
There are at least a half dozen other big reorgs waiting:
   - move syscall-level code from sys/kern/ to sys/syscall/;
   - move proc and lwp code from sys/kern/ to sys/proc/;
   - reorganize sys/sys into sys/include and move libc bits out;
   - collect all the fses into one sys/fs/ subdir;
   - collect all the net* directories into/under one net/ subdir;
   - split arch/foo/foo dirs by subsystem (dev, vfs, syscall, etc.)
     to match the kernel top level;

...some of these are debatable, but there's at least a case to be made
for all of them. But doing all of them when renames break history
would clearly be a mistake. (Otherwise they'd have been done already.)

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