From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: suparna@in.ibm.com, Andrew Morton <akpm@osdl.org>,
fastboot@osdl.org, "Martin J. Bligh" <mbligh@aracnet.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API
Date: 28 Jul 2004 09:42:52 -0600 [thread overview]
Message-ID: <m1fz7c16kj.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1091011565.30404.0.camel@localhost.localdomain>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> On Mer, 2004-07-28 at 11:54, Suparna Bhattacharya wrote:
> > On Tue, Jul 27, 2004 at 07:53:01PM -0600, Eric W. Biederman wrote:
> > > Andrew Morton <akpm@osdl.org> writes:
> > >
> > > > Keith Owens <kaos@sgi.com> wrote:
> > > > >
> > > > > * How do we get a clean API to do polling mode I/O to disk?
> > > >
> > > > We hope to not have to. The current plan is to use kexec: at boot time,
> do
>
>
> If you are prepared to say "dump device is IDE" the driver ends up
> pretty tiny - maybe 4K for PIO mode.
That sounds about right. I have a read-only version of Etherboot that
pretty much does that.
A large challenge is how do you get the IDE device into a sane state
before you use it to dump core. How do you stop on-going DMA
transactions. What about implementation errata etc. Do you need to
reprogram the drive to work in a PIO mode again. I can't quite
remember by I seem to recall that the interface to IDE drives was
fairly stateful. All of that needs to maintained in a separate dump
driver.
Plus there is the challenge that many high-end systems where people
want to employ this kind of thing have SCSI disks. At least that
has been my impression.
Using kexec to switch to an independent program to do the dump
sounds sane. If you have a simple system with just IDE you could
run a very minimal 4K IDE dumper. If you have a full sized system
you can use a kernel+initrd and do all kinds of interesting things.
Dump to disk. Dump to network etc. Stop and work interactively with
the user to examine the state of the machine when it crashed.
Basically you are only limited by how much of your system your
monitor can put into a sane state.
Plus except for a small stub the code with kernel+initrd is almost
totally user space and using the normal path for kernel drivers.
The kernel drivers that are used may need to be made a little more
robust but that is not a big deal.
What is most attractive is using kexec to put the policy in user space
seems to be the unix way.
Eric
next prev parent reply other threads:[~2004-07-28 15:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-22 16:19 Keith Owens
2004-07-26 6:57 ` Andrew Morton
2004-07-28 1:53 ` Eric W. Biederman
2004-07-28 10:54 ` Suparna Bhattacharya
2004-07-28 10:46 ` [Fastboot] " Alan Cox
2004-07-28 14:38 ` Martin J. Bligh
2004-07-28 14:06 ` Alan Cox
2004-07-28 15:21 ` Martin J. Bligh
2004-07-28 15:56 ` Eric W. Biederman
2004-07-28 17:09 ` Andrea Arcangeli
2004-07-28 16:05 ` Eric W. Biederman
2004-07-28 15:42 ` Eric W. Biederman [this message]
2004-07-28 15:12 ` Eric W. Biederman
2004-07-28 15:23 ` Martin J. Bligh
2004-07-28 15:53 ` Eric W. Biederman
2004-07-28 16:03 ` Jesse Barnes
2004-07-28 18:00 ` Eric W. Biederman
2004-07-28 18:06 ` Jesse Barnes
2004-07-28 19:42 ` Martin J. Bligh
2004-07-28 19:56 ` [Fastboot] " Alan Cox
2004-07-28 19:44 ` Andrew Morton
2004-07-28 23:11 ` [Fastboot] " Eric W. Biederman
2004-07-28 22:53 ` Alan Cox
2004-07-29 1:12 ` Eric W. Biederman
2004-07-29 14:00 ` Alan Cox
2004-07-29 15:47 ` Eric W. Biederman
2004-07-28 18:21 ` Alan Cox
2004-07-28 19:23 ` Martin J. Bligh
2004-07-28 20:28 ` [Fastboot] " Eric W. Biederman
2004-07-28 20:33 ` Andrew Morton
2004-07-28 19:59 ` Alan Cox
2004-07-28 22:42 ` Andrew Morton
2004-07-28 22:44 ` Jesse Barnes
2004-07-28 23:17 ` Eric W. Biederman
2004-07-28 22:55 ` Alan Cox
2004-07-29 0:22 ` Andrew Morton
2004-07-29 13:57 ` Alan Cox
2004-07-29 18:17 ` Andrew Morton
2004-07-29 21:20 ` Alan Cox
2004-07-29 22:30 ` Gerrit Huizenga
2004-07-30 0:04 ` Eric W. Biederman
2004-07-29 23:25 ` Alan Cox
2004-07-30 4:07 ` Eric W. Biederman
2004-07-30 12:38 ` Gerrit Huizenga
2004-07-31 13:52 ` Matthias Urlichs
2004-07-30 15:24 ` Olivier Galibert
2004-07-29 1:05 ` Eric W. Biederman
2004-07-29 14:12 ` Martin J. Bligh
2004-07-28 23:44 ` Andrew Morton
2004-07-29 0:58 ` Eric W. Biederman
2004-07-29 1:09 ` Andrew Morton
2004-07-29 1:56 ` Eric W. Biederman
2004-07-29 14:18 ` Martin J. Bligh
2004-07-29 16:01 ` Eric W. Biederman
2004-07-29 16:19 ` Eric W. Biederman
2004-07-29 14:08 ` Martin J. Bligh
2004-07-29 15:52 ` Eric W. Biederman
2004-07-29 16:13 ` Martin J. Bligh
2004-07-29 17:12 ` Matthias Urlichs
2004-07-30 15:02 Manfred Spraul
2004-07-30 14:42 ` Alan Cox
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=m1fz7c16kj.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=fastboot@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=suparna@in.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
all inboxes | Powered by JetHome®