>> OK, seeing as people don't seem to want a decent size buffer on
>> CONFIG_SMP machines, could we at least do it under
>> CONFIG_MULTIQUAD? Loosing half my boot time messages is
>> annoying, and I have gigabytes of RAM to waste. Please .......
>
> Hmm, and what exactly does prevent you from applying the patch privately
> for the time you are needing it for developent?
I don't just want it for development, I believe in capturing my boot messages
all the time. If they're not visible, why bother printing them?
Why not just keep it as a patch? Partly the fact that it's a pain in the butt,
and I keep forgetting to do it. In principle I think the default buffer ought
to big enough to cope with the boot messages we put out. There's more
messages on larger systems, hence it makes sense to have a larger buffer.
Switching on CONFIG_SMP or CONFIG_MULTIQUAD is a crude
approximation to estimating the size of boot messages.
The correct solution is probably to either size it dynamically, or have a
seperate boot time buffer that we throw away afterwards. But for the
sake of another 48Kb on machines with 2 - 16Gb of RAM, it's not worth
coding it, testing it, and risking the change.
M.
PS. Alan's solution was to turn off half the garbage that gets printed on
boot, which would work too. Especially half the stuff from the mps tables,
which we throw in the bin 2 nanoseconds after printing it. We could
turn off APIC_DEBUG by default, which would kill all the Dprintk's as
far as I can see ....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 21:00:41 EST