Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP
Path: utzoo!watmath!clyde!cbosgd!ncr-sd!greg
From: greg@ncr-sd.UUCP (Greg Noel)
Newsgroups: net.unix-wizards
Subject: Re: Why do ps, uptime (& probably others) check vmunix version?
Message-ID: <415@ncr-sd.UUCP>
Date: Thu, 20-Feb-86 17:28:22 EST
Article-I.D.: ncr-sd.415
Posted: Thu Feb 20 17:28:22 1986
Date-Received: Fri, 21-Feb-86 06:18:59 EST
References: <457@ur-helheim.UUCP> <6773@boring.UUCP>
Reply-To: greg@ncr-sd.UUCP (Greg Noel)
Organization: NCR Corporation, San Diego
Lines: 20

In article <6773@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>Something I was thinking of is teaching the boot program about symbolic
>links. That way, you can have /vmunix.1, /vmunix.2, etc.
>Now, as soon as the system comes up, some program, probably /etc/init,
>will setup a symbolic link from the currently running unix to /vmunix.

Why a symbolic link?  Why not a hard link?  We did this for a System V
port we were doing; it worked just fine.  It searched the files given
as arguments for a magic cookie that matched in low core.  (The magic
cookie was actually the date the kernel was linked, used for version
control.)  If it found a match, it unlinked /unix and linked the matching
file into place.  It was written by Mike Laman and hacked by Yours Truly.

We also had similar programs to link the proper disk partition to /dev/root
and /dev/swap; they looked in the kernel (after /unix was set properly, of
course) to find the major/minor device number and then searched /dev/dsk or
/dev/rdsk, respectivly, to find the actual device and link them into place
as well.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA