Simon Burge <simonb@netbsd.org> writes:
> As far as I can tell, this is a DEC API, not a MIPS API.  But it is most
> useful on MIPS, so I guess the "right" thing to do is implement it as an
> architecture-specific call and not a machine specific call.  Would we
> need to add the same API for VAX/Ultrix and Alpha/OSF1 compatibility as
> well?  And would it go in libc or libcompat?

(1) I think this is a reasonable thing to want an MI API for.  It's a
feature that's different on different CPUs, and MI code may well want
to use it.

(2) If there's no MI API for it, then by definition you wouldn't need
to implement it for other processors.  If you're talking about the
ABI, well, then, that's up to whoever maintains the relevant
COMPAT_XXX code.

(3) I don't think the right place could ever be libcompat, for this
type of thing, it's either libc or libarch, but it should be
consistent.


> So we'd end up with something like for MIPS:
> 
> 	atomic_op(foo, bar, ...)
> 	{
> 		static int cpu_arch = 0;
> 
> 		if (cpu_arch == 0)
> 			sysarch(GET_CPU_ARCH, &cpu_arch);

this really should be a sysctl.  I can imagine lots of things wanting
it, even from shell scripts.  (e.g. a simple script to invoke cc with
the right options to produce optimal code on the machine you're
running on.)

Note that the _presence_ of CPU, rather than architecture, -specific
sysctls may reasonably be construed to be a bug.  How do you share the
sysctl binary among systems with $(MACHINE_ARCH) == mipseX?



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.