Date: Sun, 24 Sep 1995 14:34:43 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: fenner@parc.xerox.com (Bill Fenner) Cc: current@freebsd.org Subject: Re: kernel versions and config's rm -rf Message-ID: <199509242134.OAA01414@GndRsh.aac.dev.com> In-Reply-To: <95Sep24.131401pdt.177475@crevenia.parc.xerox.com> from "Bill Fenner" at Sep 24, 95 01:13:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> I usually like to be able to tell kernel builds apart by their version
> numbers... like "oh, PARC_MROUTER #1 has the mbuf leak, you want to run
> PARC_MROUTER #2". I built a -stable kernel to test multicast routing in
> -stable, but forgot to put MROUTING in it. So I built another one, and
> then was really confused because they were both FENESTRO #0, so build date
> was my only hint as to which one I was currently running.
>
> Instead of "rm -rf", maybe config could just do "make clean; rm *.h Makefile",
> to keep the "version" file around?
I like this, it is far more appropriate than an rm -rf, but should be
reduced even further to just ``make clean; rm *.h'' and the clean: target had
better do the right things. No need to rm the Makefile, config is going
to overwrite it anyway. I can see the reasoning for rm *.h, as config and
or files{,.i386} may have changed and not rewrite all the same .h files :-(.
> Also, do we really want the kernel version number to start at 0? Under SunOS,
> my only other kernel building experience, version numbers start at 1, so to
> see all these version 0 kernels all the time kinda makes me think that
> something went wrong, and then I have to say "oh, yeah, FreeBSD's kernel
> version numbers start at 0".
This is actually, IMHO, a bug in SunOS. For example, go into the SunOS
kernel compile directory and type:
make && make && make
Note that your version number bumps and a kernel relink occurs. Now go
do it on a FreeBSD box. Note the second and later makes simply say
``kernel is up to date''. The bug is that SunOS _always_ bumps the
version number, and since that is done before the link the kernel
is always out of date :-(. SunOS copied this bug from BSD 4.2 :-(.
The reason it is a bug is that versions 2(1) and 3(2) of my kernel are infact
identical except for the version number and the compile date, which was
caused to change by the bug of bumping version when no other file changed.
Start at 0 vs start at 1, well, that is a religous issue. Unix is typically
0 based, so it should probaby start at 0. SunOS starts at 1 due to the
above ``bug''. I suggest you submit an SPR to Sun about it (I did, 10 years
ago when it was SunOS 3.2, obviously still broken :-)).
> (This is because SunOS pre-increments the version number, while FreeBSD
> doesn't. This makes sense if you want to manually set the version number,
> but it does mean that without changing newvers.sh, kernels start at 0).
And, IMHO, SunOS has gotten this wrong, see above...
> Attached is a patch for newvers.sh and for usr.sbin/config/main.c for
> someone's perusal.
>
> Bill
>
>
> --- newvers.sh.orig Sun Sep 24 12:48:32 1995
> +++ newvers.sh Sun Sep 24 12:48:55 1995
Nahh.. disagree...
> --- usr.sbin/config/main.c.orig Sun Sep 24 12:53:43 1995
> +++ usr.sbin/config/main.c Sun Sep 24 13:07:55 1995
> @@ -117,21 +117,18 @@
> exit(2);
> }
> else if (!no_config_clobber) {
> - char tmp[strlen(p) + 8];
> + char tmp[strlen(p) + 59];
>
> - fprintf(stderr, "Removing old directory %s: ", p);
> + fprintf(stderr, "Cleaning old directory %s: ", p);
> fflush(stderr);
> - sprintf(tmp, "rm -rf %s", p);
> + sprintf(tmp, "cd %s; make clean > /dev/null ; "
> + "rm Makefile machine *.c *.h", p);
That is not what you said above :-). Also what happens if %s does not
exist?? Or am I missing to much context here and we already know that
it does exist?
> if (system(tmp)) {
> fprintf(stderr, "Failed!\n");
> perror(tmp);
> exit(2);
> }
> fprintf(stderr, "Done.\n");
> - if (mkdir(p, 0777)) {
> - perror(p);
> - exit(2);
> - }
> }
> loadaddress = -1;
> dtab = NULL;
>
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509242134.OAA01414>