Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Sep 2002 18:51:24 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Peter Wemm <peter@wemm.org>
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:  <20020903183355.P6474-100000@gamplex.bde.org>
In-Reply-To: <20020902185112.1016F2A896@canning.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Sep 2002, Peter Wemm wrote:

> Bruce Evans wrote:
> > On Mon, 2 Sep 2002, Peter Wemm wrote:
> > > > On Sat, Aug 31, 2002 at 12:18:40AM -0700, Peter Wemm wrote:
> > > > [about -DBOOTSTRAPPING and newer warts]
> > >
> > > 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

One reason I don't like __FreeBSD_version is it is that using it naturally
grows more complicated as things move around or in and out.

> 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().

Heh.  I hope to fix this for __RCSID (by removing it).

> > >[SIGSYS for eaccess(2) in sh]
> > 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. :-)

Or we could stop generating SIGSYS for nonexistent syscalls and expect
applications to check for syscalls failing, as on more advanced systems
like PC BIOSes :-).

Bruce


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?20020903183355.P6474-100000>