Daniel Phillips <[email protected]> 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 <[email protected]> _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
