On Thursday 11 December 2008 11:20, OGAWA Hirofumi wrote:

quoted text
> 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

Tux3@tux3.org

http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3