On Wed, 13 Oct 1999, Jeff Garzik wrote:
> Some on linux-kernel mentioned that procfs needed cleanup. Is there a
> TODO list somewhere?
Even an initial variant of patch (ouch... porting the thing from
2.3.13-pre1 to 2.3.22-pre2 _did_ hurt; damn CVS...).
I can't promise that in the current state it _builds_, let alone works -
there were changes and testing is in order.
Sore points (partially addressed in the patch):
a) way too many places know about the layout of proc_dir_entry.
In most cases they don't need it - dynamical creation works quite fine.
I've added several functions (create_proc_*entry/remove_proc_*entry) and I
think that they should cover almost everything. See the patch for
examples of usage.
b) many moons ago, when procfs was small it was using an array of
in-core structures that imitated on-disk inodes. Some inumbers were used
by per-process stuff, some - by (then very few) special files (a-la
/proc/loadavg, etc.). Methods used to be switches. Well, it didn't scale,
so we went for the dynamic inumbers. But the old code stayed around and
some of the new procfs files went there too. Some even went into switches.
Resulting mess was _not_ nice. I tried to clean that up.
c) after the switches period the interface went through several
changes. We'ld better unify this stuff. I almost didn't touch this thing.
d) many drivers failed to unregister the entries. Each of those
cases is oopsable bug. I've fixed several such animals, but I suspect that
some are still lurking.
e) we don't need constant inumbers in procfs. If we will finally
get rid of them we will be able to simplify the permission tests in
per-process part and close several nasty holes with stale dentries.
f) proc_unregister() needs some form of revoke(). It even
implements something, but I suspect that it's racey.
g) proc/mem.c is a living horror. Look at it and you'll see.
h) per-process part really ought to be separated (codewise) from
the rest. Different needs, different races, etc...
i) tons of additional fun.
IMO the first thing that should be done is the exorcism - knowledge of
procfs guts should be driven out of the rest of tree. Then we will be able
to deal with procfs problems not causing the massive changes in the
$BIGNUM drivers. Until that will be done we can't do much with procfs
proper.
I've dropped the patch (against 2.3.22-pre2) on the
ftp.math.psu.edu/pub/viro/proc-patch-22-2.gz. Feel free to look it
through/try to test it. Comments/questions/flames to [EMAIL PROTECTED]
Cheers,
Al
