Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:5373 comp.os.386bsd.misc:1108
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!uwm.edu!news.doit.wisc.edu!psl.wisc.edu!128.104.200.15!ram
From: ram@xor.epi.wisc.edu (Ram Bhamidipaty)
Subject: Re: kernel names
In-Reply-To: jboggs@umaxc.weeg.uiowa.edu's message of Fri, 24 Sep 1993 13:27:59 GMT
Message-ID: <RAM.93Sep24121853@xor.epi.wisc.edu>
Lines: 50
Sender: news@pslu1.psl.wisc.edu (USENET News System)
Reply-To: ram@epidat.epi.wisc.edu
Organization: Physical Sciences Lab, UW-Madison
References: <27ufsh$75q@Germany.EU.net> <1993Sep24.132759.29302@news.weeg.uiowa.edu>
Date: 24 Sep 1993 17:18:53 GMT
> |> ln -s /netbsd /vmunix
> |>
> |> or
> |>
> |> ln -s /386bsd /vmunix
> |>
> |> Knock yourself out...
>
> Now that you mention it, this was exactly what I did with 386bsd 0.0 where
> most of the stuff still insisted on opening /vmunix.
>
> Bernard
John> And is what I've done on Net-BSD-0.9 to get xload to work.
John> [ln -s /netbsd /386bsd]
Hmm, for some strange reason it does not work for me...good thing
I have the source for xload on hand :-) Any clues?
janis:ram {20} ls -l /
total 2896
lrwxrwxr-x 1 root 6 Sep 24 12:22 386bsd -> netbsd
-rwxr-xr-x 1 root 452641 Sep 23 23:20 netbsd
-rwxr-xr-x 1 root 522251 Sep 1 01:08 netbsd_orig
-rwxr-xr-x 1 root 452974 Sep 21 17:30 netbsd_prev
...
janis:ram {21} xload
xload: cannot get name list from /386bsd
janis:ram {22}
-Ram
--
--------------
Ram Bhamidipaty use this ->ram@epidat.epi.wisc.edu
Department of Preventive Medicine or this->ram%epidat.decnet@macc.wisc.edu
University of Wisconsin, Madison Ignore the header. It might be wrong.
#! rnews 2434 sserve.cc.adfa.oz.au
Xref: sserve comp.unix.bsd:12678 comp.unix.wizards:30921 comp.sys.sun.apps:4887 comp.sys.sun.misc:9722
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!hal.com!decwrl!vixie!efficacy!vixie
From: vixie@gw.home.vix.com (Paul A Vixie)
Newsgroups: comp.unix.bsd,comp.unix.wizards,comp.sys.sun.apps,comp.sys.sun.misc
Subject: Re: checkpointing software for UNIX or SunOS
Date: 25 Sep 93 16:43:56
Organization: Vixie Enterprises
Lines: 30
Message-ID: <VIXIE.93Sep25164356@gw.home.vix.com>
References: <TMB.93Sep23012442@arolla.idiap.ch> <VIXIE.93Sep22202934@gw.home.vix.com>
<27scjl$qjc@agate.berkeley.edu> <2823de$5l4@crystal.WonderWorks.com>
NNTP-Posting-Host: gw.home.vix.com
In-reply-to: kyle@crystal.WonderWorks.com's message of 25 Sep 1993 14:41:50 -0400
Kyle Jones:
> [...] The surprises are unimaginable. The only way I found to do it
> portably was to have the program write its internal data out as C
> structures and then recompile itself. I did this for a LISP system a few
> years ago, and the only portability problem I've had to date is that the
> large C data files produced made pcc gag.
Once we give up on doing it in the kernel (see my previous message for details)
and decide that the application has to cooperate with the checkpointing, it
seems obvious (famous last words) that the right answer is for an application
to manage its state in a way that is easy to checkpoint. All of the global
variables needed for restarting can be put into a struct or otherwise grouped
together so that it can be written out to a file and possibly read at startup.
There's no reason to write out all of the data space; lots of the stuff there
is going to be transient, even though global.
An application which is likely to need checkpointing should be written with
that in mind. Which means that careful thought must be given to any static
variable. It's tough to get right but it's not easier to do in the kernel or
at the compiler level. I just had a thought about shared libraries and the
fact that the _res struct in libresolv.a tends to change size from time to
time. To do checkpointing in the system it would have to be integrated with
the dynamic loader if any. The slope just gets slipperier and slipperier.
Directions taken by the rest of the system have made checkpointing so hard
that it's now more work than it's worth.
--
Paul Vixie
Redwood City, CA
<paul@vix.com>
decwrl!vixie!paul