Re: [PATCH] 2.4.16 kernel/printk.c (per processorinitializationcheck)

[David Mosberger]

>>>>> On Fri, 7 Dec 2001 18:47:11 -0200 (BRST), Marcelo Tosatti <[e-mail]> said:

  Marcelo> On Fri, 7 Dec 2001, David Mosberger wrote:

  >> >>>>> On Fri, 7 Dec 2001 16:52:07 -0200 (BRST), Marcelo Tosatti
  >> <[e-mail]> said:
  >> 
  Marcelo> I'm really not willing to apply this kludge...
  >>  Do you agree that it should always be safe to call printk() from
  >> C code?

  Marcelo> No if you can't access the console to print the message :)

Let me quote the first few lines of the Linux kernel:

	----
	asmlinkage void __init start_kernel(void)
	{
		char * command_line;
		unsigned long mempages;
		extern char saved_command_line[];
	/*
	 * Interrupts are still disabled. Do necessary setups, then
	 * enable them
	 */
		lock_kernel();
		printk(linux_banner);
	----

You still think it doesn't make sense?

  Marcelo> Its just that I would prefer to see the thing fixed in
  Marcelo> arch-dependant code instead special casing core code.

Only architecture specific problems should be fixed with architecture
specific code.

I'm not entirely sure whether this particular problem is architecture
specific.  Perhaps it is and, if so, I'm certainly happy to fix it in
the ia64 specific code. However, are you really 100% certain that on
x86 there are no console drivers which in some fashion depend on
cpu_init() having completed execution?  Note that the x86 version of
cpu_init() also has printk()s.  If you're not certain of this, the AP
startup problem could occur on x86, too.  I haven't looked at all the
other platforms, but I suspect similar things will be true, there.

	--david