Re: [Kgdb-bugreport] [PATCH] Kill kgdb_serial

From: George Anzinger (george_at_mvista.com)
Date: 03/04/04

  • Next message: Rik van Riel: "Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)" 
    Date:	Thu, 04 Mar 2004 14:02:54 -0800
To: "Amit S. Kale" <amitkale@emsyssoft.com>

    Amit S. Kale wrote:
    > On Thursday 04 Mar 2004 6:04 am, George Anzinger wrote:
    >
    >>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 ***, 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.
    >
    >
    > I would prefer something that modifies start_kernel itself, rather than
    > depending on ld. It will split start_kernel command line parsing into early
    > parse and late parse, but that's the price we have to pay to do special
    > parsing of kgdb arguments.

    There was some talk along these lines at one point, I don't think anything came
    of it. We would like it to be the very first, not just one of the first.

    I think modifying the kernel to support this for kgdb is more like the tail
    wagging the dog :) 

    -- 
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Rik van Riel: "Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)"
    • Quantcast