Subject: Re: /usr/include/machine
To: None <tsutsui@ceres.dti.ne.jp>
From: None <cgd@sibyte.com>
List: tech-kern
Date: 07/16/2001 10:32:14
tsutsui@ceres.dti.ne.jp ("Izumi Tsutsui") writes:
> > kernel it's on.
>
> Currently, any {mipsel,mipseb,m68k,powerpc,sh3el} binary run on
> any {mipsel,mipseb,m68k,powerpc,sh3el} archtecture.
> So that is not a reason to introduce "a new technique."
The little voices in my head are squabbling again:
"Really? So, if compile a program on NetBSD/pmax, for instance, that
pulls in <machine/fbio.h> and uses its contents, that program will
have the intended effect when run on, say, a NetBSD/arc system? or
any other NetBSD mipsel system?"
"No, it won't. You're using a machine-dependent header file with
machine-dependent contents, and you can't expect them to work across
all members of the architecture!"
"But surely, that's not right! It's a frame buffer IOCTL definition,
and it's in a location not in any way obviously NetBSD/pmax specific!"
"Ahh, but <machine/...> is magic! Half the stuff in there is
machine-specific, the rest is architecture specific."
"Oh, OK, so, i should only use stuff in there that's defined on all
ports in the architecture?"
"Yes, exactly!"
"OK, like disklabel.h?"
"No, no, it exists on all of the ports, but if you use it incorrectly
you'll trash your disks! The values of the important definitions that
it provides are different!"
"OK, then, what in <machine/...> can I be _sure_ is safe to use in a
machine-independent program for an architecture?"
"Well, without looking at every individual file... You can't."
"But, files in <sys/...> include files from <machine/...>! Do you
mean that all of those are known to be compatible?"
"Yes. At times, extra effort has even been made to keep things used
by MI files, e.g. sysctl numbers, compatible!"
"Ahh, but the, what aboud <sys/disklabel.h> that includes
<machine/disklabel.h>?"
"<head explodes>"
If we're trying to provide a machine-independent API and ABI for a
particular architecture, we should arrange things such that:
(1) You don't need any special effort (e.g. sysctl value issues)
expended to keep things in sync.
(2) You don't actually get _incompatible_
definitions/functions/etc. unless you specifically ask for the
machine-dependent files.
That means (as far as i'm concerned) <machine/...> should be provided
by the architecture code, and where MI code really needs MD values, MI
code should use portable abstractions to get it -- not just differing
#define values.
I've been trying to encourage people to take the system in this
direction for several years now. looks like some people are actually
doing it. "YAY!"
cgd