Re: RFC: New kernel proc interface

Rob Riggs (
Fri, 01 Nov 1996 03:42:09 -0700 (MST)

On 01-Nov-96 Keith Rohrer wrote:
>>Rob Riggs wrote:
>> The current proc code was the best solution when RAM was limited.
>> Today's systems have much more RAM than in the past. Hacks like
>> this should be elimnated now that the majority of systems have
>> the resources to do "the right thing." (TM)
>> If this is really an issue, implimenting backwards compatibilty
>> for memory critical proc routines is trivial.

>Actually, I'd be much more interested in backwards compatibility by
>'make config', but that would defeat the purpose of your efforts.
>Although, the 4-meg box I'm considering pulling down 1.2.latest for
>doesn't actually need /proc for much...

Please note 2 items:

- The point Alan brought up does not affect Joe Average User,
but rather very busy network boxes. And it will only be a
problem on very busy network boxes that are tight on memory
_and_ needs to access the /proc/net files.

- My goal is to actually eliminate some of the kernel bloat
by making generic proc routines that most of the current proc
code can be easily modified to use. The end result will be
make Linux a little leaner.

A vast majority of Linux users will notice only a slight increase
in kernel memory usage with the patch in place. When I get the
chance to start eliminating some of the duplicate code in the kernel,
Joe A. User should actually notice a _decrease_ in kernel size (and
related memory usage).

That being said, I need to know where this patch will cause problems
and what I need to watch out for. I am also a little concerned by
how long it would take the kernel to write out 40K worth of route
information (using Alan's example) since many proc routines just
use cli/sti to lock down the tables that they are operating on.