[Tux3] Userland cleanups

[OGAWA Hirofumi]

Daniel Phillips <phillips at phunq.net> writes:

> 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.

I see. I was trying to include buffer.c to tux3 rather. I'll try to
think about it.

> 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.

Maybe, it can't be inline func. Because, it allocates inode on stack, so
the stack of inline func may be invalid after func (not sure).

> 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.

I thought the volmap inode lives in tux3 always, so I thought own inode
number would be useful for debug. In the logmap case, I thought own
inode number may be useful for debug, however I thought we can handle it
as delalloc inode number (TUX_INVALID_INO) later. (But, since we may not
use delalloc inode number anymore, it may not be true)

Well, anyway, we can just remove inode number if insert_inode_hash() was
removed.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>

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