I started to rewrite procfs to use the dcache for dynamic entries
(i.e. the not on-the-fly generated ones).
This is done by using the d_revalidate operation to create the inode,
if necessary. The dcache does the tree/name/lookup management.
For this implementation I need to
- add a union to dentry like the inode.u union to hold a pointer
to the proc_dir_entry (which holds a pointer to the dentry)
- implement readdir scanning the dentry tree - are there any locking
issues I have to cope with?
Is it wrong to use the super_block directly rather than getting it
via proc_dir_entry->dentry->d_parent->d_inode->i_sb ??
In the first place I tried to implement the proc_dir_entry struct
as extension of a dentry, i.e. sort of
struct proc_dir_entry {
struct dentry dentry;
other stuff...
};
and have the dcache do the memory management. I gave up this solution
because of the lack of a 'extra needed space' argument of d_alloc and
other minor issues. Is there an other good and nice way to have a
similar scheme? Or should I stay with the seperate dentry/proc_dir_entry?
Another change is to provide one generic pair of inode_operations/
file_operations containing generic lseek/read/write/readdir and
lookup/readlink (all in one iop/fop). Is this bad? Do we really need
seperate file_i/fop dir_i/fop and link_i/fop ??
In the old proc_dir_entry there were the read/write callbacks. I
made this more generic providing an union of callbacks for files,
directories and links (actually read/write, readdir/lookup and readlink).
For now I changed the read/write callbacks to match the vfs interface
and not the old proc callback interface. Comments? Any use of
generic unlink/create callback?
I have patches, but they do not compile at the moment ;-)
Compiling and 'minimal entry' patches will appear at the weekend, probably.
Richard.
-- Richard Guenther <richard.guenther@student.uni-tuebingen.de> PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57 WWW: http://www.anatom.uni-tuebingen.de/~richi/