Date: Mon, 02 Sep 2002 11:51:12 -0700 From: Peter Wemm <peter@wemm.org> To: Bruce Evans <bde@zeta.org.au> Cc: "David O'Brien" <obrien@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src Makefile src/usr.bin/make Makefile Message-ID: <20020902185112.1016F2A896@canning.wemm.org> In-Reply-To: <20020903011057.W3883-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> On Mon, 2 Sep 2002, Peter Wemm wrote:
>
> > "David O'Brien" wrote:
> > > On Sat, Aug 31, 2002 at 12:18:40AM -0700, Peter Wemm wrote:
> > > [about -DBOOTSTRAPPING and newer warts]
>
> > > I thought we were going to impliment these warts with some form of
> > > __FreeBSD_version test -- so they don't impact source bases that don't
> > > need them, and more importantly so it is documented the time range they
> > > cover so we know when to remove them.
> >
> > Go for your life. Personally, I think that this sort of stuff should be
> > removed from critical bootstrap tools with extreme prejudice.
>
> I hope you mean including the __FreeBSD_version wart.
Actually, the __FreeBSD_version tests might be pretty complicated now.
Especially since it comes from different headers. <osreldate.h> on older
systems, <sys/param.h> on newer ones. I'd rather we just reset make back
to use __RCSID (since that is in all BSD sys/cdefs.h) or plain static const
char rcsid[] = "string"; since that works on everything. But *definately*
not __FBSDID here, the #if's and crud needed to make this work would be worse
than any percieved cosmetic gain from using __FBSDID().
> > Next problem: make has got /bin/sh hardcoded by absolute path. This burns
> > us during an 4.x->5.x upgrade when /bin/sh is replaced before make has
> > finished running things and the freshly installed /bin/sh gets a SIGSYS on
> > eaccess(2). If that is solved, then we can avoid one reboot.
>
> I have used a hacked test/test.c with a function named eaccess() since this
> problem first bit me. I sometimes boot old kernels that don't have eaccess(2
).
> Current kernels from 2 years ago still mostly work with current userlands
> apart from this. (Many sysctls and things like ps don't work. More
> interestingly, soft updates causes panics when a file is removed.)
Or, if we want to get really evil, we could set a SIGSYS handler the first
time we try and call eaccess() and revert to plain access() if the syscall
isn't present. :-)
> Bruce
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?20020902185112.1016F2A896>