From: George Anzinger <george@mvista.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Pavel Machek <pavel@ucw.cz>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
kgdb-bugreport@lists.sourceforge.net,
"Amit S. Kale" <amitkale@emsyssoft.com>
Subject: Re: [Kgdb-bugreport] [PATCH] Kill kgdb_serial
Date: Wed, 03 Mar 2004 16:34:33 -0800 [thread overview]
Message-ID: <40467999.8000106@mvista.com> (raw)
In-Reply-To: <20040303160409.GT20227@smtp.west.cox.net>
Tom Rini wrote:
> On Wed, Mar 03, 2004 at 04:51:06PM +0100, Pavel Machek wrote:
>
>>Hi!
>>
>>
>>>>>More precisely:
>>>>>http://lkml.org/lkml/2004/2/11/224
>>>>
>>>>Well, that just says Andrew does not care too much. I think that
>>>>having both serial and ethernet support *is* good idea after all... I
>>>>have few machines here, some of them do not have serial, and some of
>>>>them do not have supported ethernet. It would be nice to use same
>>>>kernel on all of them. Also distribution wants to have "debugging
>>>>kernel", but does _not_ want to have 10 of them.
>>>
>>>But unless I'm missing something, supporting eth or 8250 at all times
>>>doesn't work right now anyhow, as eth if available will always take over.
>>
>>Well, that can be fixed. [Probably if kgdbeth= is not passed, ethernet
>>interface should not take over. So user selects which one should be
>>used by either passing kgdbeth or kgdb8250. That means that 8250
>>should not be initialized until user passes kgdb8250=... not sure how
>>you'll like that].
>
>
> At this point, I'm going to give up on killing kgdb_serial, and pass
> along some comments from David Woodhouse on IRC as well (I was talking
> about this issue, and the init/main.c change):
> (Tartarus == me, dwmw2 == David Woodhouse)
>
> <Tartarus> dwmw2, the problem is how do you deal with all of the
> possibilities of i/o (8250, kgdboe, or other serial) and do you allow
> for passing 'gdb' on the command line to result in kgdb not being dropped
> into? You can always break in later on of course
> <dwmw2> parse command line early for 'gdb=' argument specifying which
> i/o device to use. init kgdb core early. init each i/o device as early
> as possible for that i/o device. Start the selected i/o device as soon
> as it becomes available.
> <dwmw2> just like console could, if we looked for console= a little bit
> earlier. (forget all the earlyconsole shite, it's not necessary)
> <dwmw2> Tartarrus, do the __early_setup() thing to replace __setup() for
> selected args. We can use that for console= too.
> <dwmw2> since 'console=' on the command line _already_ remembers its
> arguments, and starts to use the offending device as soon as it gets
> registered with register_console().
> <Tartarus> dwmw2, __early_setup() ?
> <dwmw2> See __setup("gdb=", gdb_setup_func);
> <dwmw2> Replace with __early_setup(...)
> <Tartarus> where is __early_setup ?
> <dwmw2> before we normally parse the command line
> <dwmw2> in my head
>
> So perhaps someone can take these ideas and fix both problems... :)
> (I've got some other stuff I need to work on today).
Well, __early_setup could mean the fist setup call and if so that would be what
we do in -mm. It is done by putting the code in the first module ld sees, not
nice, but it works.
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2004-03-04 0:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-02 21:39 [PATCH] Kill kgdb_serial Tom Rini
2004-03-02 22:02 ` [Kgdb-bugreport] " George Anzinger
2004-03-02 22:11 ` Tom Rini
2004-03-02 22:31 ` Pavel Machek
2004-03-02 22:41 ` Tom Rini
2004-03-02 23:00 ` Tom Rini
2004-03-02 23:35 ` Pavel Machek
2004-03-03 15:22 ` Tom Rini
2004-03-03 15:51 ` Pavel Machek
2004-03-03 16:04 ` Tom Rini
2004-03-04 0:34 ` George Anzinger [this message]
2004-03-04 5:01 ` Amit S. Kale
2004-03-04 22:02 ` George Anzinger
2004-03-04 22:48 ` Tom Rini
2004-03-02 23:46 ` George Anzinger
2004-03-02 23:52 ` Tom Rini
2004-03-03 0:36 ` George Anzinger
2004-03-03 15:20 ` Tom Rini
2004-03-04 0:30 ` George Anzinger
2004-03-03 5:43 ` Amit S. Kale
2004-03-03 15:16 ` Tom Rini
2004-03-04 0:27 ` George Anzinger
2004-03-04 15:17 ` Tom Rini
2004-03-04 22:18 ` George Anzinger
2004-03-04 22:49 ` Tom Rini
2004-03-04 4:41 ` Amit S. Kale
2004-03-04 15:27 ` Tom Rini
2004-03-04 23:06 ` George Anzinger
2004-03-04 23:17 ` Tom Rini
2004-03-11 21:33 ` George Anzinger
2004-03-11 22:33 ` Tom Rini
2004-03-11 22:53 ` George Anzinger
2004-03-11 23:00 ` Tom Rini
2004-03-11 23:46 ` George Anzinger
2004-03-12 4:52 ` Amit S. Kale
2004-03-12 4:48 ` Amit S. Kale
2004-03-03 15:26 ` Matt Mackall
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=40467999.8000106@mvista.com \
--to=george@mvista.com \
--cc=amitkale@emsyssoft.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=trini@kernel.crashing.org \
/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.