From: "Luck, Tony" <tony.luck@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] SAL error record logging/decoding
Date: Thu, 29 May 2003 23:33:49 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590723706084@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590723705660@msgid-missing>
> There is a certain appeal to using a single file, at least from
> the application perspective. Let's run this up the flagpole
> and see whether anybody salutes:
>
> - we export two files: "control" and "data"
> - app uses poll(2) on "control"
> - SAL log events set a bit for CPU and event type
> and do a wakeup
> - app returns from poll()
> - app reads "control"
> - kernel supplies "cpu 5 cpe" as read(2) data
> - app writes same data ("cpu 5 cpe") to "control"
> - app reads "data"
> - kernel calls GET_STATE_INFO and supplies
> raw data to app
> - app writes "clear cpu 5 cpe" to "control"
> - kernel clears CPU/event bit, calls CLEAR_STATE_INFO,
> and calls GET_STATE_INFO, does wakeup if more data
>
> Is that too ugly for words? It keeps the unadorned SAL data,
> requires only two files, and could probably even be driven from
> a shell script (if we make read(2) on "control" blocking). It
> feels sort of Plan 9-ish, which is always appealing. Plus, it
> avoids the problem of having hundreds of "cpuXXXX" directories
> on all those monster SGI boxes :-)
>
> There might be fairness issues if events occur faster than the
> app reads them -- might have to round-robin through the
> CPUs when supplying "control" data. Or we could use a pair
> of files for each type of event, i.e., /proc/sal/mca/{control,data}.
Seems odd that we read "cpu 5 cpe" from the "control" file, and then
turn around to write the same thing back to the same file.
Perhaps you are overloading the function of the control file? With
three files: {event,control,data} you get all the above functionality,
but with a simpler to understand interface.
Applications block reading the "event" file (or use poll(2) on it) to
find out that it is worth reading. When they read, they see the "cpu
5 cpe" type message. They write that to "control", and then read from
"data".
Or, back to two files: {event,data} ... we read from "event" to see
what happened. Writing to "data" controls what will be read from "data".
-Tony
next prev parent reply other threads:[~2003-05-29 23:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-07 23:41 [Linux-ia64] SAL error record logging/decoding Bjorn Helgaas
2003-05-08 0:05 ` David Mosberger
2003-05-08 0:13 ` Luck, Tony
2003-05-08 19:32 ` Bjorn Helgaas
2003-05-20 22:58 ` Bjorn Helgaas
2003-05-21 18:06 ` Luck, Tony
2003-05-21 20:48 ` Luck, Tony
2003-05-21 21:51 ` Luck, Tony
2003-05-22 21:29 ` Bjorn Helgaas
2003-05-23 0:24 ` Bjorn Helgaas
2003-05-23 15:42 ` Luck, Tony
2003-05-28 23:26 ` Bjorn Helgaas
2003-05-29 0:07 ` Keith Owens
2003-05-29 1:34 ` Bjorn Helgaas
2003-05-29 1:37 ` Keith Owens
2003-05-29 20:49 ` Luck, Tony
2003-05-29 21:31 ` Bjorn Helgaas
2003-05-29 21:47 ` Luck, Tony
2003-05-29 22:38 ` Bjorn Helgaas
2003-05-29 23:33 ` Luck, Tony [this message]
2003-05-30 11:56 ` Matthew Wilcox
2003-05-30 20:27 ` Bjorn Helgaas
2003-05-30 20:31 ` Bjorn Helgaas
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=marc-linux-ia64-105590723706084@msgid-missing \
--to=tony.luck@intel.com \
--cc=linux-ia64@vger.kernel.org \
/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