[Top] [All Lists]

Re: Dump driver interface

To: Castor Fu <castor@xxxxxxxxxxxx>
Subject: Re: Dump driver interface
From: "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx>
Date: Tue, 09 Oct 2001 16:16:57 -0700
Cc: Suparna Bhattacharya <suparna@xxxxxxxxxx>, lkcd@xxxxxxxxxxx
Organization: Alacritech, Inc.
References: <Pine.LNX.4.33.0110091044280.22562-100000@marais>
Sender: owner-lkcd@xxxxxxxxxxx
Castor Fu wrote:
> On Tue, 9 Oct 2001, Suparna Bhattacharya wrote:
> > On Mon, Oct 08, 2001 at 11:46:42PM -0700, Matt D. Robinson wrote:
> > >
> > > I think you've covered most of it.  The real key here is making sure
> > > to maintain as little stuff as possible in the dump functionality for
> > > each device driver.  That device operation is responsible for knowing
> > > what to do when it is called, in terms of configuring the driver
> > > state, reading flags, and writing out pages of data to disk.  For it
> > > to do more than that, such as understanding higher level kernel
> > > structures,
> > > would not be a good thing.

> One thing that might be nice, (I'm still on the fence on this matter), is to
> structure the code so it could be standalone code outside of the linux kernel.

In what sense?  Right now, we're a module, but I suspect you aren't referring
to this.

> This would imply factoring out the iteration through pages of memory and
> device write routines.  In this case, various linux kernel parameters
> might also not be available.

Are you referring to something like LinuxBIOS?  Just curious.  We have
briefly discussed something like this, along with putting in MCL's code.


<Prev in Thread] Current Thread [Next in Thread>