[Tux3] Userland cleanups

[Daniel Phillips]

On Friday 09 January 2009 05:22, OGAWA Hirofumi wrote:
> Hi,
> 
> This cleanups userland stuff. map->dev removal is unnecessary, so if
> someone disklike it, I can drop it.
> 
> Well, this make simple sb/inode user, on stack sb/inode is setted up by
> macros, so we can avoid strace thing by unsetup sb/inode.
> 
> And, with this, we can share tux_new_volmap() in both of userland and
> kernel.
> 
> 	static-http://userweb.kernel.org/~hirofumi/tux3/
> 
> Please review and pull if ok.
> 
> Thanks.

A lot of nice cleanups.  Having the dev only in one place, the sb, is
good.

One thing I was trying to do is keep buffer.c from knowing details of
Tux3, such as inode format.  Mainly so that it could be used for some
other project, the same way I borrowed it from ddsnap.  I don't know
how important that is, perhaps not very important.  Anyway, an easy
resolution is to make map_dev external.  Then buffer can go back to
having its own includes and not including tux3.h.

Can rapid_new_inode be an inline instead of macro?  RAPID_INIT_SB has
to be a macro.  These will make the unit test code easier to maintain,
indeed.

Somehow this got in twice:

+	       tux_inode(inode)->inum == TUX_VOLMAP_INO ||
+	       tux_inode(inode)->inum == TUX_VTABLE_INO ||

Having a VOL_INO is a hack too, but not as bad a hack as invading the
kernel S_IVOL space.  These are both just to be able to use
tux_setup_inode for the volume, right?  I would prefer not to invade
our inode number space, but that can just be a FIXME.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3