lkml.org 
[lkml]   [1998]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PROPOSAL: /proc/dev
On Thu, 1 Jan 1998, Linus Torvalds wrote:

>
> 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.

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.184 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site