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.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
[->i_ino users] (If I'm missing something, please let me know)
1) printk()
In some places, kernel users ->i_ino for printk()
2) /proc/locks, /proc/<pid>/{maps,smaps}
Those show the ->i_ino
3) pipefs - pipefs_dname()
It uses ->i_ino as part of filename. This may not matter?
4) fs/nfsd/export.c:exp_hash()
This uses ->i_ino. Since it may be for hash key, so it's ok?
5) audit (CONFIG_AUDIT)
audit (CONFIG_AUDIT) uses ->i_ino to check if it is interesting inode.
6) selinux
Current tree seems _not_ to use ino, however, variant may use?
7) NFS ->get_name()
default handler uses ->i_ino ...
