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 [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
