>>>>> On Mon, 15 Jan 1996, Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU 
writes:

> on the i386, various procfs files size to:

> 12 [sun-lamp] GENERIC % size procfs_*
> text    data    bss     dec     hex
> 904     312     0       1216    4c0     procfs_ctl.o
> 232     0       0       232     e8      procfs_fpregs.o
> 564     0       0       564     234     procfs_mem.o
> 60      0       0       60      3c      procfs_note.o
> 228     0       0       228     e4      procfs_regs.o
> 924     0       0       924     39c     procfs_status.o
> 964     0       8       972     3cc     procfs_subr.o
> 488     52      0       540     21c     procfs_vfsops.o
> 3076    500     0       3576    df8     procfs_vnops.o

> 13 [sun-lamp] GENERIC % size ../SUN_LAMP/procfs_*
> text    data    bss     dec     hex
> 232     0       0       232     e8      ../SUN_LAMP/procfs_fpregs.o
> 564     0       0       564     234     ../SUN_LAMP/procfs_mem.o
> 228     0       0       228     e4      ../SUN_LAMP/procfs_regs.o
> 
> the latter set are the 'standard' ones that are used by ptrace (which
> in a perfect world would live elsewhere and be named differently, but
> there's history there).


I don't quite understand the point here.  If I add up list "12" and 
subtract list "13", I get:

text    data    bss
6416	864	8

So, this is roughly 2 4k pages on the i386 (depending on how the page 
boundaries come out).  I think kernfs is about the same size or smaller 
(depending on how many of these talked-about improvements get added 
eventually).  Even on my 8MB machine, 8k is pretty small potatoes.  Compare 
this with the price of adding audio or CDROM/isofs or msdosfs (typically 
25-50k apiece, if my memory serves).

True, this doesn't address the original point about whether the added 
functionality of kern/proc fs is worth > 0k.  

I think the problem here, as has already been pointed out, is the 
chicken-and-egg thing.  If one insists that kernfs and procfs be 
"optional," then no one will write gdb to use procfs, or xload to use 
kernfs, or the clever install program to read configured devices from 
/kern/dev/...,  etc.  Therefore, there will never be any added 
functionality to make these two things anything more than "toys".  I think 
this is an unfortunate missed opportunity because I like the idea of 
kernfs/procfs, and I think it really simplifies things for the applications 
programmer (certainly compared to kernel nlist; a matter of taste compared 
to sysctl()).  Unfortunately, I don't have any really impressive ideas of 
what to do with these filesystems in order to convince you.  Perhaps 
someone else will come up with those great ideas, though, if we give them a 
chance.



Tom Pavel

Stanford Linear Accelerator Center
pavel@slac.stanford.edu                 http://www.slac.stanford.edu/~pavel/