From: Karim Yaghmour <karim@opersys.com>
To: Michael Raymond <mraymond@sgi.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
LTT-Dev <ltt-dev@shafik.org>, Tom Zanussi <zanussi@us.ibm.com>,
Robert Wisniewski <bob@watson.ibm.com>,
Mathieu Desnoyers <compudj@krystal.dyndns.org>,
Michel Dagenais <michel.dagenais@polymtl.ca>
Subject: Re: [ltt-dev] [PATCH/RFC] Significantly reworked LTT core
Date: Sat, 02 Jul 2005 12:06:17 -0400 [thread overview]
Message-ID: <42C6BB79.8070903@opersys.com> (raw)
In-Reply-To: <42C6A58B.6020000@opersys.com>
Karim Yaghmour wrote:
> I think this one needs more thinking ... I did think about adding such a
> hook, but I didn't like the idea of it, it just seems unclean. After all
> the problem is limited to a very small subset of events, namely NMIs and
> page fault traps. One thing I was thinking about is that in both these
> cases there's always an entry event and an exit event. ltt_mux could then
> coordinate using these events. IOW, if it just got an NMI entry, it
> doesn't allow any other event to get logged until it sees the NMI exit
> go by ... same for page faults. By doing this, we can just keep just one
> hook: ltt_mux. Right?
Brain was slow this morning. What we're trying to do is to avoid getting
those very NMIs and page faults into the logging path if we're already
in that path ... That's different from what my brain came up with this
morning. We may need that hook after all ... something like:
if (ltt_post)
ltt_post(...);
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
next prev parent reply other threads:[~2005-07-02 15:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-02 2:46 [PATCH/RFC] Significantly reworked LTT core Karim Yaghmour
2005-07-02 13:14 ` [ltt-dev] " Michael Raymond
2005-07-02 14:32 ` Karim Yaghmour
2005-07-02 16:06 ` Karim Yaghmour [this message]
2005-07-02 16:04 ` Christoph Hellwig
2005-07-02 21:15 ` Karim Yaghmour
2005-07-07 14:11 ` Christoph Hellwig
2005-07-08 13:20 ` Karim Yaghmour
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=42C6BB79.8070903@opersys.com \
--to=karim@opersys.com \
--cc=bob@watson.ibm.com \
--cc=compudj@krystal.dyndns.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=michel.dagenais@polymtl.ca \
--cc=mraymond@sgi.com \
--cc=zanussi@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox