linux-kernel - Re: Early printk behaviour

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Aug 2007 14:56:30 -0400
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	"Gerd Hoffmann" <kraxel@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Early printk behaviour

On Thu 16 Aug 2007 03:45, Gerd Hoffmann pondered:
> Robin Getz wrote:
> > I was putting together an early printk implementation for the Blackfin, and 
> > was wondering what the expected behaviour was in this situation.
> > 
> > When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console 
> > defined (no graphical console, no serial console).
> > 
> > based on the patch:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
> > 
> > which no longer calls disable_early_printk, the earlyprintk console never gets 
> > turned off (because nothing else ever calls register_console). I get 
> > everything out the early console, until the init section is released (where 
> > the console structure is sitting), and it starts printing out garbage.
> > 
> > Is this expected behaviour?
> 
> Hmm, sort of, although I didn't think about the case of no real console
> replacing the early console.  The intention of the patch is to have a
> smooth handover from the boot console to the real console.  And, yes, if
> no real console is ever registered the boot console keeps running ...
> 
> So you can either let it running and *not* mark it __init, so it can
> keep on going without breaking.  Or you can explicitly unregister your
> boot console at some point, maybe using a late_initcall.

Thanks.

Doing things with late_initcall seems to work - is there any problem calling
unregister_console on an already unregistered console? I looked in the code,
and didn't see any nastyness.

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