alloc_dentry and alloc_filp

[Brice Goglin <Brice.Goglin@ens-lyon.fr>]

Hi,

I would like to know why the alloc_inode/destroy_inode functions
have been added to super block operations during 2.5 development
while there still are no alloc/destroy_dentry or alloc/destroy_filp
functions.
It seems that the alloc_inode enhanced several filesystems such
as NFS, JFS, XFS, etc. But it also seems to me that similar
alloc_dentry or alloc_filp fields may also be interesting.

I looked at the usage of the private_data field of the struct file
in 2.6.1 filesystems and I think several implementations may be
enhanced by allowing filesystems to control the allocation of
struct file.
For instance, Coda could move its "struct coda_file_info" into
the main struct file.
Other examples are the struct dir_private_info of ext3,
presto_file_data in intermezzo, nfs4_state in nfs4, etc.

The usage of d_fsdata field in struct dentry shows that Intermezzo
may also be enhanced by allowing it to control dentry allocation
so that its struct presto_dentry_data would be allocated within
the dentry.

I imagine a simple patch adding in get_empty_filp/d_alloc a check
for the existence of alloc_file/dentry in the super block operations
and then call it or revert to the generic allocation routines.
Corresponding dentry/filp_init_once might then be exported as
inode_init_once is.

Looking at the current dentry/file allocation model in 2.6, I
didn't find any problem with that. What do you think about it ?
Has anobody already tried this ?
Any chance for such a patch to be included ?

Best regards
-- 
Brice Goglin
================================================
Ph.D Student
Laboratoire de l'Informatique et du Parallélisme
CNRS-INRIA-ENS Lyon
France