Re: alternate /proc/config.gz patch and a kfree question.

Peter T. Breuer (ptb@it.uc3m.es)
Sun, 31 May 1998 08:50:57 +0200 (MET DST)


"A month of sundays ago Andrew J. Anderson wrote:"
> Some things that are different between the 2 patches:
>
> 1) It looks like the other config.gz patch uses one page of kernel memory
> for the buffer. This is probably fine for the compressed .config file for

I.e. 4K? Where? What buffer? Oh - a memcpy?

memcpy(page,ucTable,sizeof(ucTable));

The implementation I worked across into 2.0.* added an extra file
in the proc root. When that file is read it uses a get_proc_config()
function that does the above memcpy and nothing else. I don't know
any details of where memory is used or not behind the scenes - and I'd
like to know so please tel me! - but this is the way all the proc
files are done. It looks an ephemeral use of memory to me.

> quite some time. My implementation goes a step further and actually
> implements file operations for this which can handle arbitrarily large
> files, as you'll see in #2). As more and more features get added, this

But my full config < 1K. You are preparing for more than 4 times that?
Surely this is something to mend later, not now.

> may be an issue eventually.
>
> 2) My implementation also copies into itself the System.map *ONLY* if it
> is compiled as a module. Beneficial? Maybe -- one of the people that

I can't see any sense in using a module for the config functionality,
unfortunately. The module may not match the kernel.

> 3) If you `echo "foo" > /proc/config.gz` it will free up the memory (3

Good. I'll look for that.

> pages or 12K on i386 in my tests), thus reducing the "bloat" argument. It

Good. I'll look for that.

> This should go cleanly into 2.1.103. I have a module-only version for
> 2.0.x that I did the "feasibility study" on also. It doesn't do the
> tricks in #3, though.
>
> I've also tried to be certain that all cases are handled WRT cleanup
> whether or not the /proc files have been removed or not. If anyone gets
> this to break I'd be interested in hearing about it.

Whilst this is good stuff, as an engineer I'd say "keep it simple to
start with". Put these extra things in later, only if you need to. At
the moment this all sounds heavyweight.

Peter ptb@it.uc3m.es

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu