On Thursday 11 December 2008 11:20, OGAWA Hirofumi wrote: > Hi, > > I think this adds some improvements, and makes some todo appear. > > With this, ->inum has the real inode number (64bit), and ->i_ino (may > 32bit) is used as just hash value. But it has issue like the below > list. (So, we may want to add ->read_ino() handler or something. > ->i_ino is hidden more or less from userland, but it is not perfect. > If we have ->read_ino() handler to return the real inode number (same > with stat64->ino), generic_* stuff may become more generically.) > > tux_new_inode() was introduced. We initialize the new inode with it. > And TODO, now it saves almost all attributes, but we would want to > optimize it by removing unneeded attributes. > > The preparation of device special file support was done. TODO, we have > to load/store the rdev valude from/to ileaf. So, we have to decide the > size of rdev. (Now kernel uses the 32bit device number internally (new_*), > but there is the preparation of the 64bit device number (huge_*). > And glibc seems to already use 64bit to prepare for the future.) > > NOTE, and this changes the inum field size in dirent from 32bit to > 64bit. Of course, it is for storing the 64bit inum. However, this means > it changes the on-disk format. > > Per-patch comment is in repo as usual, > > static-http://userweb.kernel.org/~hirofumi/tux3/ > > Please review.
The change to 64 bit ino in dir.c is a disk format change and requires a rev of the date part of the superblock magic. I will pull first, then do that... pulled, user built perfectly, make tests ran, kernel built perfectly, booted up... the tests I use for ext2 ran... Check_present is a nice add, the iget5 stuff is very cool, supporting 48 bit ino on 32 bit arch is very very cool. Awesome patch set :-) Regards, Daniel _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
