Messages in this thread | | | Date | Tue, 30 Oct 2001 10:19:01 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH] making the printk buffer bigger |
| |
>> 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/
| |