Re: log-buf-len dynamic

[Willy Tarreau]

Hi Andrea,
 
> The point here is that the default must work for 99% of the userbase.
> Either that or the default is totally broken.

You're only thinking about what distro vendors should do. If all kernels should
suit their needs, then there would not be any config anymore, and everyone
would have the same kernel with the same wagon of command line arguments.

Lots of people actually do recompile their kernel to change a few options from
the vendor config, and that's the expected behaviour. And be it 1%, I consider
that 1% of Linux users are *lots* of people.

> And only this 1% would be the one recompiling the kernel
> by themself anyways, and if they can recompile the kernel they can as
> well edit the defaults in kernel/printk.c without pain.

I don't agree. That's what I did for a long time, and finally got bored of it.
Then I wrote a patch and proposed it. Randy Dunlap had one included in 2.6, and
Marcelo thought this one would be useful to lots of people, *exactly* because
it avoids what you describe here, ie. changins constants by hand.

> I don't buy much the lazyness argument in changing lilo.conf, the people
> who need this feature is a marginal part so they must be ok with the
> parmeter. And don't tell me that you don't pass root= to the kernel at
> boot. Do you want to fix that too? I do pass plenty of argumetns all the
> time, starting from profile=0 (and often acpi=off).

sorry, I don't agree with you on this. My lilo.conf contains "root=/dev/root"
and "boot=/dev/mbr" on nearly all my systems, just because it's easier ton
maintain, especially those which are patched remotely. You are speaking about
a developer's system, and I too have lots of crap on my desktop machines, and I
too am regularly annoyed because lilo tells me that 19 boot images is the max.
But on production systems, you need to avoid tricks, and even more when other
people manage the system after you install it.

> however I won't complain if you put the compile time configurator on top
> of my patch (that's easy) but personaly I think it's not needed, and
> having it dyanmic is an order of magnitude more important than having it
> static

I said I agree on the dynamic advantage. BTW, you didn't reply me about what
the statically allocated 64 kB became with your patch. Will this memory be
wasted forever or is there a way to free it ? If I want to pre-allocate it
dynamically with alloc_space() as you did, what can I use to free it ? is
kfree() the right thing ?

Cheers,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/