Subject: Re: procfs/kernfs "required"? [was Re: kernel & libkvm... ]
To: None <Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU, greywolf@captech.com>
From: James Graham - Systems Anarchist <greywolf@defender.VAS.viewlogic.com>
List: current-users
Date: 01/15/1996 14:17:34
#define AUTHOR "Chris_G_Demetriou@niagara.nectar.cs.cmu.edu (Chris_G_Demetriou@niagara.nectar.cs.cmu.edu)"

/*
 * > /*
 * >  * > ...so tossing in /proc is negligible.
 * >  * 
 * >  * Without even ATTEMPTING to state the size of adding procfs, where do
 * >  * you come off stating _that_?
 * >  * 
 * > 
 * > Comparatively, it's negligible.  It's still taking up less memory than
 * > SunOS does.  You really can't argue with that. :-)
 * 
 * According to this logic, i should feel free to add a 5MB array of
 * nothing to the NetBSD/Alpha kernel, because if I did it would still be
 * smaller than the OSF/1 kernel i normally run on my workstation.
 * 
 * Of course, compared to say, some real-time kernels, the NetBSD kernel
 * is huge...
 * 

More info:

After configuring kernels which were IDENTICAL except for procfs,
the 'size' output from the kernel showed:

819168  63952   78560   961680  eac90   netbsd		# no procfs
819168  64832   78584   962584  eb018   /netbsd		# procfs

And on disk:

-rwxr-xr-x  1 root  bin  958261 Jan 12 19:05 netbsd	# no procfs
-rwxr-xr-x  1 root  bin  960266 Jan 12 18:01 /netbsd	# procfs

The difference in core appears to be 0+880+32; the difference
on disk appears to be 2005 bytes.

Now, tell me that 2 kilobytes of disk space and 912 bytes of core is
worth worrying about for the functionality (for what it is worth) of
procfs.  You're picking at nickels and dimes.  True, if we have a lot of
them, they add up, but we're only looking at _one_, here.

Rhetorically and theoretically, your analogy holds and makes sense, and
the point is taken.  However, converting this _precise_ point to
real numbers kind of blows it out of the water this time.  Hence I
stand by my statement:  The cost of procfs is negligible.

 * 
 * Keeping a system trim and avoiding bloat isn't about being smaller
 * than a comparable system...  You may feel _good_ of you system is
 * smaller than a comparable system, but that's not the point.

Well, no and yes. :-) You must admit that being smaller than a comparable
system is on the road to avoiding bloat and keeping a system trim, though
it may not be the end goal.  If this is not the case, then our graph is
a good 180 degrees out of phase with reality.

 * 
 * 
 * cgd
 * 
 */

#undef AUTHOR	/* "Chris_G_Demetriou@niagara.nectar.cs.cmu.edu (Chris_G_Demetriou@niagara.nectar.cs.cmu.edu)" */





				--*greywolf;
--
DAFFYNITIONS
    Demonstrate (DEH m@n strayt) 1. vi.  To remove beasts from, as in a
    dungeon.  (L 'de-', negation + OE 'monster', beast + ME '-ate', perform).
    2. n. A layer of underworld beasties, or, if dealing with computers,
    the ghost in the machine ( L 'demon', beast + 'strata', layers).