From: George Anzinger <george@mvista.com>
To: "Amit S. Kale" <amitkale@emsyssoft.com>
Cc: Matt Mackall <mpm@selenic.com>, Pavel Machek <pavel@ucw.cz>,
kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@zip.com.au>
Subject: Re: kgdb cleanups
Date: Wed, 14 Jan 2004 12:35:51 -0800 [thread overview]
Message-ID: <4005A827.80704@mvista.com> (raw)
In-Reply-To: <200401141834.51536.amitkale@emsyssoft.com>
Amit S. Kale wrote:
> On Wednesday 14 Jan 2004 2:23 am, George Anzinger wrote:
>
>>
>>>>An alternate possibility is an array of pointer to struct kgdb_hook
>>>>which allows one to define the struct contents as below and to build the
>>>>array, all at compile/link time. A legal entry MUST define get and put,
>>>>but why not define them all, using dummy functions for the ones that
>>>>make no sense in a particular interface.
>>>
>>>Throwing all the stubs in a special section could work well too. Then
>>>we could add an avail() function so that early boot debugging could
>>>discover if each one was available. The serial code could use this to
>>>kickstart itself while the eth code could test a local initialized
>>>flag and say "not a chance". Which gives us all the architecture to
>>>throw in other trivial interfaces (parallel, bus-snoopers, etc.).
>>
>>I am thinking of something more like what was done with the x86 timer code.
>>Each timer option sets up a structure with an array of pointers to each
>>option. There it is done at compile time, and the runtime code tries each.
>>There it is done in order, but here we want to do it a bit differently.
>>
>>Maybe we could have an "available" flag or just assume that the address
>>being !=0 for getdebugchar means it is "available". I think there should
>>be a prefered intface set at config time. Possibly over ride this with the
>>command line. Then have a back up order in case kgdb wants to communicate
>>prior to the prefered one being available.
>>
>>We would also have a rule that the command line over ride only works if
>>communication has not yet been established. Here, we would also like
>>control from gdb/kgdb so we could switch to a different interface, but
>>under gdb control at this point. Either a maintaince command or setting
>>the "channel" with a memory modify command. We would want this to take
>>effect only after the current command is acknowledged.
>
>
> I have something similar in my patches.
> Each interface has kgdb_hook function, which returns failure if an interface
> isn't ready.
Keep in mind that an interface may be ready to communicate and still not able to
handle the ^C break. The reason is that the ^C requires interrupt support which
is not available until rather late in the bring up. In particular, trying to
register an interrupt routine prior to the memory subsystem being able to do an
alloc causes failure to register the interrupt function, which does cause and
error return from request_irq(). The version in the common.patch seems to keep
this information but does nothing with it. I think it would be better to try
again later and to keep trying until the request is successful. See for
example, the kgdb patch in Andrew's mm breakout.
--
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-01-14 23:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-09 18:38 kgdb cleanups Pavel Machek
2004-01-09 21:41 ` Andrew Morton
2004-01-09 21:54 ` George Anzinger
2004-01-10 4:47 ` Matt Mackall
2004-01-10 8:12 ` George Anzinger
2004-01-10 17:56 ` Matt Mackall
2004-01-10 19:34 ` Pavel Machek
2004-01-10 19:37 ` Matt Mackall
2004-01-12 5:41 ` George Anzinger
2004-01-12 6:49 ` Matt Mackall
2004-01-12 9:45 ` Pavel Machek
2004-01-13 20:54 ` George Anzinger
2004-01-13 21:00 ` Pavel Machek
2004-01-12 13:53 ` Amit S. Kale
2004-01-13 21:20 ` George Anzinger
2004-01-14 13:20 ` Amit S. Kale
2004-01-14 20:40 ` George Anzinger
2004-01-13 20:53 ` George Anzinger
2004-01-14 13:04 ` Amit S. Kale
2004-01-14 20:35 ` George Anzinger [this message]
2004-01-10 15:15 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2003-12-28 14:13 Pavel Machek
2003-12-28 20:14 ` Robert Walsh
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=4005A827.80704@mvista.com \
--to=george@mvista.com \
--cc=akpm@zip.com.au \
--cc=amitkale@emsyssoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=pavel@ucw.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox