All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Russell King <rmk@arm.linux.org.uk>
Cc: Stuart MacDonald <stuartm@connecttech.com>,
	Khalid Aziz <khalid@fc.hp.com>,
	Linux kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Support for serial console on legacy free machines
Date: 31 Jul 2001 21:21:54 -0600	[thread overview]
Message-ID: <m18zh4zcq5.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200107302332.f6UNWbxg001791@webber.adilger.int> <3B65F1A2.30708CC1@fc.hp.com> <000701c119cd$ebf0c720$294b82ce@connecttech.com> <20010731174247.A21802@flint.arm.linux.org.uk>
In-Reply-To: <20010731174247.A21802@flint.arm.linux.org.uk>

Russell King <rmk@arm.linux.org.uk> writes:

> On Tue, Jul 31, 2001 at 10:34:35AM -0400, Stuart MacDonald wrote:
> > That's very odd. That implies that serial consoles don't use the serial
> > driver at all then, as the pci serial port setup is done at the same
> > time as the regular serial port setups.
> > 
> > If a serial console is using serial.c, the pci serial ports will also
> > be available.
> 
> No.  Console initialisation is done early, before PCI is setup.  This
> means that the serial driver is relying on a static array of IO port
> addresses.  At this time, the serial driver hasn't probed any ports at
> all, so it doesn't really know what does and doesn't exist.

Hmm. I hadn't realized it was poking in the dark.
 
> The more I think about this, the more that I think we need to get rid
> of this early console initialisation.  I think Linus really wants early
> console initialisation though, and to be honest, its an extremely useful
> debugging tool for those pesky non-boots with blank displays.

I think I both agree and disagree with you.  I think it might make sense
to seperate out the debugging console drivers from the normal kernel drivers.
I have had several times where I have had to hack up a serial driver that
is initialized very early so I could see why my kernel is crashing.

If we seperated out the console drivers and modified them so they would
build for specific hardware, and would be initialized immediately upon
transition to C code.  There would be a major debugging benefit.  

Then we could probably afford to use the normal serial code for a more
normal serial console.

Does this sound like a reasonable direction to go?  You've torn open
the code and familiar with what it's guts look like.


> If someone would like to produce a patch which adds an option for early
> console vs "normal" console initialisation...  Otherwise I'll add it to
> my (longish) "to do" list.

I might have to look.  I have done some preliminary work, in getting a
very, very early serial console built so I'm not completely in the
dark.  If you like the idea of splitting the console code in two half
that uses normal routines and another have that does very, very, very
early initialization I'm more likely to :)

Eric


  parent reply	other threads:[~2001-08-01  3:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-30 21:26 Support for serial console on legacy free machines Andreas Dilger
2001-07-30 21:38 ` Khalid Aziz
2001-07-30 22:40   ` Andreas Dilger
2001-07-30 22:53     ` Jan-Benedict Glaw
2001-07-30 22:53     ` Maciej W. Rozycki
2001-07-30 23:00     ` Khalid Aziz
2001-07-30 23:17       ` Randy.Dunlap
2001-07-30 23:39         ` Khalid Aziz
2001-07-30 23:52           ` Randy.Dunlap
2001-07-30 23:32       ` Andreas Dilger
2001-07-30 23:40         ` Ignacio Vazquez-Abrams
2001-07-30 23:45         ` Khalid Aziz
2001-07-31 14:34           ` Stuart MacDonald
2001-07-31 15:54             ` Miquel van Smoorenburg
2001-07-31 16:00             ` Eric W. Biederman
2001-07-31 16:10             ` Khalid Aziz
2001-07-31 16:39             ` Andreas Dilger
2001-07-31 18:43               ` Russell King
2001-08-01  2:01               ` Keith Owens
2001-07-31 16:42             ` Russell King
2001-07-31 17:14               ` Stuart MacDonald
2001-07-31 18:46                 ` Russell King
2001-08-01  3:21               ` Eric W. Biederman [this message]
2001-08-01  3:39                 ` Ignacio Vazquez-Abrams
2001-07-31  1:33     ` Keith Owens
2001-07-31  4:50       ` Johannes Erdfelt
2001-07-31 16:15         ` Khalid Aziz
2001-07-29 20:47           ` Alan Cox
2001-07-31 16:20           ` Randy.Dunlap
     [not found] <no.id>
2001-07-26 22:20 ` Alan Cox
2001-07-30 17:47   ` Khalid Aziz
  -- strict thread matches above, loose matches on Subject: below --
2001-07-26 21:13 Khalid Aziz
2001-07-27 13:28 ` Simon Richter
2001-07-30 17:49   ` Khalid Aziz
2001-07-30 18:21 ` Rik van Riel
2001-07-30 19:39   ` Khalid Aziz

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=m18zh4zcq5.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=khalid@fc.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=stuartm@connecttech.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.