badri@ur-helheim.UUCP (Badri Lokanathan) (02/10/86)
We run BSD4.2 on a 750.
I installed a new vmunix and did not link it to /vmunix, but left it
as /vmunix.blah. Then I booted with B/1 and entered the appropriate
stuff. Well, it booted off fine; everything was OK till I checked
uptime and ps and got garbage. I tracked down the problem in the
source of ps to the following:
getkvars(argc, argv)
char **argv;
{
register struct nlist *nlp;
nlistf = argc > 1 ? argv[1] : "/vmunix";
.
.
.
Since /vmunix was linked to the old version of vmunix, naturally it barfed.
So, here is my question. Why should ps (and any other program) examine the
name of vmunix? This is particularly aggravating if a new kernel is being
tested - I do not want to make too many changes, just in case.
My apologies if I sound terribly naive!
Badri Lokanathanwcl@hjuxa.UUCP (Bill Loeffler) (02/13/86)
In article <457@ur-helheim.UUCP>, badri@ur-helheim.UUCP (Badri Lokanathan) writes: > So, here is my question. Why should ps (and any other program) examine the > name of vmunix? This is particularly aggravating if a new kernel is being > tested - I do not want to make too many changes, just in case. > My apologies if I sound terribly naive! > These commands check the time of /unix (vmunix). One System V, this time is compared to the time of /etc/ps_data. /etc/ps_data contains data nessary to lseek into /unix. If /unix was created after /etc/ps_data, the commands update ps_data from the name list. This is done to save the time and CPU required to read the name list each time ps is used. You will note the first ps after linking a new UNIX will take longer. -- Bill Loeffler Digital Equipment Corp., Holmdel NJ 07733 uucp: ...!{decvax,ihnp4}!hjuxa!wcl
jack@boring.uucp (Jack Jansen) (02/14/86)
In article <457@ur-helheim.UUCP> badri@ur-helheim.UUCP (Badri Lokanathan) writes: >Since /vmunix was linked to the old version of vmunix, naturally it barfed. >So, here is my question. Why should ps (and any other program) examine the >name of vmunix? This is particularly aggravating if a new kernel is being >tested - I do not want to make too many changes, just in case. It has to check. It gets the addresses of kernel variables by looking in the namelist of /vmunix, and those variables are likely to be on different addresses if you run another kernel. V7 didn't check anything, which meant that 'ps' gave you lots of garbage when you ran it if you had booted from a different kernel (it tried to interpret random junk as, for instance, the process table. This is likely to produce dissapointing results). 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. So, besides the fact that 'ps' works as expected, you will automatically have the effect that a reboot will automatically reboot the currently running kernel. To get a different kernel running, you just ask for a reboot by name. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
greg@ncr-sd.UUCP (Greg Noel) (02/21/86)
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
adh@cstvax.UUCP (Adam Hamilton) (02/26/86)
In article <415@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >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 >............... Our System V does a "uname" to get the version then links this file in /etc/namelists to /unix. It's VERY convenient in a development environment and when new base versions arrive. And all you have to do is keep the version numbers unique :-)