All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: "Amit S. Kale" <amitkale@emsyssoft.com>
Cc: Andrew Morton <akpm@osdl.org>,
	jim.houston@comcast.net, discuss@x86-64.org, ak@suse.de,
	shivaram.upadhyayula@wipro.com,
	lkml <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [discuss] Re: kgdb for x86_64 2.6 kernels
Date: Wed, 14 Jan 2004 14:32:01 -0800	[thread overview]
Message-ID: <4005C361.8050006@mvista.com> (raw)
In-Reply-To: <200401141854.23423.amitkale@emsyssoft.com>

Amit S. Kale wrote:
> On Wednesday 14 Jan 2004 2:56 am, George Anzinger wrote:
> 
>>Amit S. Kale wrote:
>>
>>>8250.patch changes generic 8250/16550 driver behavior only in following
>>>ways 1. It adds a function serial8250_release_irq to release those serial
>>>ports which share an irq with kgdb irq.
>>>2. There are checks so that a serial port that uses an irq used by an
>>>initialized kgdb can't be initialized or started.
>>>
>>>File kgdb_8250.c is independent of 8250.c kgdb_8250.c depends on
>>>KGDB_8250 and 8250.c depends on SERIAL_8250 which can be independently
>>>configured. kgdb_8250.c can be compiled even if 8250.c is not included.
>>>kgdb_8250.c does only the _minimum_ set of initializations required by
>>>hardware.
>>
>>Ok.
>>
>>
>>>Serial interface should be configurable independent of kgdb and may not
>>>be configured if ethernet interface is configured.  Serial interface is
>>>far simpler hence superior for debugging purposes. If it's available,
>>>using ethernet interface is out of question. Ethernet interface can be
>>>used when serial hardware isn't present or is being used for some other
>>>purposes.
>>
>>I rather think that the serial inteface should be the fall back unless the
>>user has told us at configure time that it is not available.  I am not
>>prepared to make a statment that it is better than eth.  The eth intface
>>should be much faster, but it has its fingers into a large part of the
>>kernel that MAY be the subject of the current session.  Thus, I think that
>>eth may be better, IF one is clearly not involved in debugging those areas
>>of the kernel.  (Which, by the way, we need to enumerate at some point.)
> 
> 
> Ethernet interface spans a large part of the kernel, so is going to be limited 
> in near future. When it becomes as minimal as the serial interface, both may 
> be given equal priority.
> 
> At 115kbps, serial interface is usable even when doing a thread list of 200 
> threads.

Only 200? :)

Yes, I agree, but the thing I see about the eth interface is that it allows much 
more remote debugging, like accrost the country, and it is every so much easier 
to set up.  I don't know about you, but my experience with rs232, which after 
all, can only be wired one of two ways, it that the probability of getting it 
wrong is about 90%.

-g
-- 
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


  reply	other threads:[~2004-01-14 23:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000e01c3d476$2ebe03a0$4008720a@shivram.wipro.com>
     [not found] ` <1073603622.993.353.camel@new.localdomain>
     [not found]   ` <20040108153243.11e45156.akpm@osdl.org>
     [not found]     ` <200401091031.41493.amitkale@emsyssoft.com>
2004-01-09 22:16       ` [discuss] Re: kgdb for x86_64 2.6 kernels George Anzinger
2004-01-10 10:41         ` Amit S. Kale
2004-01-10 15:03           ` Pavel Machek
2004-01-10 18:14           ` Pavel Machek
2004-01-12 14:32             ` Amit S. Kale
2004-01-10 19:30           ` Pavel Machek
2004-01-12 14:31             ` Amit S. Kale
2004-01-12  6:00           ` George Anzinger
2004-01-12  9:47             ` Pavel Machek
2004-01-13 20:55               ` George Anzinger
2004-01-12 14:50             ` Amit S. Kale
2004-01-13 21:26               ` George Anzinger
2004-01-14  6:31                 ` Matt Mackall
2004-01-14 20:02                   ` George Anzinger
2004-01-14 23:26                     ` Greg KH
2004-01-15  0:02                       ` George Anzinger
2004-01-15  0:19                         ` Pavel Machek
2004-01-15  3:28                           ` George Anzinger
2004-01-15  0:23                         ` Greg KH
2004-01-15  3:30                           ` George Anzinger
2004-01-14 13:24                 ` Amit S. Kale
2004-01-14 22:32                   ` George Anzinger [this message]
     [not found] <1cd9t-4Su-65@gated-at.bofh.it>
     [not found] ` <1coR2-42n-19@gated-at.bofh.it>
     [not found]   ` <1d3r0-1tw-3@gated-at.bofh.it>
     [not found]     ` <1dbI9-89t-7@gated-at.bofh.it>
     [not found]       ` <1dEqx-F0-1@gated-at.bofh.it>
     [not found]         ` <1dMRc-6DQ-3@gated-at.bofh.it>
     [not found]           ` <1e2Mk-6YA-17@gated-at.bofh.it>
     [not found]             ` <1e2Mo-6YA-31@gated-at.bofh.it>
     [not found]               ` <1e3fi-4nG-5@gated-at.bofh.it>
2004-01-15  8:02                 ` Andi Kleen
2004-01-15  8:36                   ` George Anzinger
2004-01-15  8:52                     ` Andi Kleen
2004-01-16  1:15                       ` Matt Mackall
2004-01-16 18:04                         ` Randy.Dunlap
2004-01-16 21:07                           ` Andi Kleen

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=4005C361.8050006@mvista.com \
    --to=george@mvista.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=amitkale@emsyssoft.com \
    --cc=discuss@x86-64.org \
    --cc=jim.houston@comcast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=shivaram.upadhyayula@wipro.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.