Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API

[Eric W. Biederman]

Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx> writes:
> > > 
> > > > Keith Owens <kaos@xxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/