Date: Tue, 12 Mar 2002 11:58:37 -0800 From: Peter Wemm <peter@wemm.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Jake Burkholder <jake@locore.ca>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/savecore savecore.c Message-ID: <20020312195837.C5AFA380A@overcee.wemm.org> In-Reply-To: <xzpbsdtvaa5.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > Peter Wemm <peter@wemm.org> writes: > > I'm not sure that will cut it, the entire structure of the dump has to > > change since phsyical ram will probably not be contiguous and will probably > > not start at address zero either. > > I was thinking a while back (when I made savecore() write sparse > files) that dumpsys() and its minions should be able to write sparse > dumps (to avoid writing out unused areas). I guess I'll just have to > follow up on that thought :) The problem is that it is that dumpsys() does nothing at all with regards to doing the actual dumping. All of the dumping code, accessing physical ram etc, is done in the MI drivers. This is wrong. What needs to happen is that dumpsys() decides on the dump device, checks the slices etc, and then finds three helper functions in the MI drivers. It then should call the MD backend dump driver, and that MD backend should call the driver "prepare for dump" setup function, arrange the mappings, call the driver "dump these pages" function, do all the looping etc, and then finally call the driver "finish the dump" shutdown function. This then means that we have a MD place to do the physical page mapping and controlling the loops etc, as well as controlling what other structured info gets written out. This basically means taking each of the dump routines, splitting it into 4 parts (setup, loop, write pages, finish), and moving the loop part to a MD area (or MI to start with, in dumpsys itself for now, since the drivers are currently MI). That probably means changing devsw from one dump function to three, or changing the meaning of the dump function so that it returns the three pointers somehow. It isn't a small job to do and test. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020312195837.C5AFA380A>