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

[Tom Rini]

On Thu, Mar 04, 2004 at 10:31:00AM +0530, 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 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.
> 
> 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's two things here, that it's important not to loose sight of.
First, it's not just kgdb that could stand to parse things earlier on
(console, as dwmw2 points out).  Second, unless we're going to throw in
the initalizations of the i/o drivers manually, we're already depend on
ld to do things right.

Besides, this is probably going to be the cleanest way to get things
working like we want them to, not how they work now :)

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