mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: matthew@wil.cx, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] CON_BOOT
Date: Wed, 16 Mar 2005 13:09:48 -0800	[thread overview]
Message-ID: <20050316130948.678ca2f2.akpm@osdl.org> (raw)
In-Reply-To: <20050316130759.GL21986@parcelfarce.linux.theplanet.co.uk>

Matthew Wilcox <matthew@wil.cx> wrote:
>
>  I think it's doable
>  if we do something like:
> 
>   - Add an int (*takeover)(struct console *); to struct console
>   - Replace the hunk above with:
> 
>  	for (existing = console_drivers; existing; existing = existing->next) {
>  		if (existing->takeover && existing->takeover(console)) {
>  			unregister_console(existing);
>  			console->flags &= ~CON_PRINTBUFFER;
>  		}
>  	}
> 
>  That puts the onus on the early console to be able to figure out
>  whether a registering console is its replacement or not; for the x86_64
>  early_printk, that'd be as simple as comparing the ->name against "ttyS"
>  or "tty".  It'll be a bit more tricky for PA-RISC, but would solve some
>  messiness that we could potentially have.  I think that's doable; want
>  me to try it?

It doesn't sound terribly important - I was just curious, thanks.  We can
let this one be demand-driven.

I'm surprised that more systems don't encounter this - there's potentially
quite a gap between console_init() and the bringup of the first real
console driver.  What happens if we crash in mem_init()?  Am I misreading
the code, or do we just get no info?

  reply	other threads:[~2005-03-16 21:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-15 22:27 Matthew Wilcox
2005-03-15 22:37 ` Andrew Morton
2005-03-16 13:07   ` Matthew Wilcox
2005-03-16 21:09     ` Andrew Morton [this message]
2005-03-16 21:17       ` Matthew Wilcox
2005-03-16 21:52         ` James Simmons
2005-03-16 21:54       ` James Simmons
2005-03-16 22:57         ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050316130948.678ca2f2.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome