>
> Finally, I think it would be good to try to use the dcache to actually
> remember the names of the files rather than having a separate data
> structure for names. Too bad we didn't have the dcache when the original
> /proc was done, but these days you could actually populate /proc with the
> generic dcache functions:
[...]
>
> Anyway, something like the above would be very powerful and avoid keeping
> filenames around anywhere but in the dcache..
>
> Linus
>
I started on this kind of proc filesystem about three month ago, but
never finished due to lack of time and the following problems:
- we need an inode for every dentry. I tried to create them on the fly
at lookup, using negative dentries and a d_revalidate - but the problems
start at needing to i_get them there ... now where i_put them.
(Currently inodes get created at first lookup, never freed... this leads
to another problem:)
- the d_count handling can not be done in the usual way, because (as we
want to be able to umount/mount proc several times and of cause keep
the proc-tree) the mount/umount syscalls and followups have ugly (dont
rembember all) superblock->d_root handling. Ah yes, and of cause
dentry->d_sb needs to change automagically, because proc has no real
device id.... (partial fixes exist).
- dentries don't have a user data field (easy to fix, suggested by other
people, too)
BTW. the VFS looks to the iops to decide whether a file is a directory/link,
why not look at inode->i_mask? This would let us put the usual file_iops,
dir_iops and link_iops into one structure? Is there _any_ reason for not
doing this??
Richard.
PS: if patches (early alphas) of the proc2 (TM) fs are recommended - please
ask.