lkml.org 
[lkml]   [2004]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Kgdb-bugreport] [PATCH] Kill kgdb_serial
On Wed, Mar 03, 2004 at 12:35:12AM +0100, Pavel Machek wrote:
> On ?t 02-03-04 16:00:18, Tom Rini wrote:
> > On Tue, Mar 02, 2004 at 11:31:43PM +0100, Pavel Machek wrote:
> >
> > > Hi!
> > >
> > > > > Tom Rini wrote:
> > > > > >Hello. The following interdiff kills kgdb_serial in favor of function
> > > > > >names. This only adds a weak function for kgdb_flush_io, and documents
> > > > > >when it would need to be provided.
> > > > >
> > > > > It looks like you are also dumping any notion of building a kernel that can
> > > > > choose which method of communication to use for kgdb at run time. Is this
> > > > > so?
> > > >
> > > > Yes, as this is how Andrew suggested we do it. It becomes quite ugly if
> > > > you try and allow for any 2 of 3 methods.
> > >
> > > I do not think that having kgdb_serial is so ugly. Are there any other
> > > uglyness associated with that?
> >
> > 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.

--
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.310 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site