Date: Fri, 01 Oct 1999 03:56:14 +0800 From: Peter Wemm <peter@netplex.com.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Amancio Hasty <hasty@rah.star-gate.com>, Marcel Moolenaar <marcel@scc.nl>, current@FreeBSD.ORG Subject: Re: HEADS UP: sigset_t changes committed Message-ID: <19990930195614.2834A1CA7@overcee.netplex.com.au> In-Reply-To: Your message of "Thu, 30 Sep 1999 00:32:14 MST." <19990930003214.58194@hydrogen.fircrest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote: [..] > might as well say goodbye to ever getting freebsd's userland running > under NetBSD which is how our nice Alpha port got started... this > NEEDS to be fixed... NetBSD have just done exactly the same sort of thing. And for that matter it makes no difference for that sort of thing as we used a different syscall set explicitly in that case. The only "problem" is that -current libc is tightly bound to the -current kernel. How about this as a cheap and robust "solution": - when building libc, have an option that allows sigaction etc to be *wrappers* that emulate their functionality through osigaction(). This means dropping sigaction etc from the assembler function list and use some C stubs instead. Call this (say) -DANCIENTTOOLS for the Makefiles. The objective would be to try not to generate a binary that requires syscalls that are not present on something like 2.2.x. - -DANCIENTTOOLS would be both a make define and a C define, so makefiles could use .if defined(ANCIENTTOOLS) ... to disable new stuff and C code could use #ifdef ANCIENTTOOLS or #ifndef etc. This would mean it would be a lot easier to build make(1) as well since it could avoid using stuff that is only in the latest systems. - this could be used on other libraries (eg: consumers of issetugid()) - what this buys us is we can build the static libraries and build tools with -DANCIENTTOOLS and they'll run on anything from 2.2 onwards. - this can also be used to do some workarounds for old gcc's etc for the build tools too. - this enables us to build the /usr/obj/tmp tree hosted for >= 2.2.x but they are -current tools for compiling the *rest* of the system including the real build tools. I think this would solve a lot of chicken/egg problems and would solve the signal syscall issue thing completely. So far we've been lucky. None of the 40-50 odd new syscalls we've added over the last few years have been used in building the tree, so folks have had it easy for a while. Marcel has done *nothing* wrong. This was bound to blow up sooner or later when we added a new syscall that was used during the build. So how about folks get off Marcel's back and stop running around like it's the end of the world and lets do a proper workaround. Rest assured, this will be resolved with a workaround of some sort or other and will be a 4.0-RELEASE requirement that 3.x-stable can do a source upgrade to 4.0. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990930195614.2834A1CA7>