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

Jeanette Pauline Middelink (middelin@polyware.nl)
Sun, 31 May 1998 11:18:16 +0200


On Sun, May 31, 1998 at 08:50:57AM +0200, Peter T. Breuer wrote:
> "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));
Hmm, file functions seem a bit overkill, couldn't you just
make your patch do the following:

memcpy(page,ycTable+ppos,count);

(with the needed bounderies checking and passing of count,pps ofcourse?)
This way we still have a minimalist interface to the ucTable
array, without loosing malloced memory.

> > 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.
And even then... Why bother? the ucTable can be longer than 4K
without problems, and with some more parameter passing you can
easaly adapt the memcpy to honour the requested size and offset.

> > 3) If you `echo "foo" > /proc/config.gz` it will free up the memory (3
>
> Good. I'll look for that.
Why? Since you didn't allocate any memory in the first place, this
is a no-op.

> > 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.

Right. I like the simple approach too, and with some little changes
it will support the >4K files too. Why all the mallocing and stuff?
The intention is to have a _nonchanging_ file, since I have never
seen a configuration change in a running kernel!

Met vriendelijke groet,
Pauline Middelink

-- 
PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0  58 A3 06 9D B6 34 39 E2
For more details look at my website http://www.polyware.nl/~middelin

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