I understand why people would feel what I'm going to say is overly
pedantic, but I absolutely agree with Andrew:  these are single
instructions for a singular architecture.  The fact that removing
function definitions from the kernel headers broke certain packages
that relied on them is--IMHO--yet another artifact of programmers
taking linux-specific design decisions (I'll leave any value
judgements concerning these decisions to the reader ...) for granted
because they're momentarily convenient.  By my lights, at least (as
I'm far from expert in these matters), this seems ultimately to be
similar to using "magic numbers" instead of defining constants--or any
number of other mistakes which are mentioned in the initial chapters
of "The C Programming Language".  On the other hand, I don't expect
our removing these from the installed headers to affect any sort of
major change in programming practices--an unfortunate number of people
seem to neglect other far more significant NetBSD design decisions
already.  I imagine some might argue that these are such simple
instructions that it wouldn't hurt to have them in our headers for
convenience and to comply with "tradition", but IMHO that's just one
more reason that I don't think it's unreasonable for programmers to
define them in their own headers should they need to use them.  After
all, in general I imagine one wants to avoid such things!

If this issue is a pain, perhaps we could deal with it in pkgsrc,
maybe in a manner similar to pkgtools/posix_headers.  Moreover, there
is a third-party library written by the author of vbetool called
"libx86" (which I think might be sublated in some form into the latest
version of vbetool).  It's basically a wrapper/"thunking layer" (am I
using that term correctly?) which acts as a wrapper to either LRMI or
x86emu depending upon the target architecture.  See thunk.c in
vbetool, then google "libx86" and you'll see what I'm talking about.
It's easy enough to port programs to use this:  I even did it back
when I'd barely had any experience in C (though it took a while, heh).

OK, enough said on such a simple topic.  I think I might've written
this much due to spending too much time in the DRM code lately. ;)

Regards,

--Blair