Re: Compatability: missing sys/vm86.h

[Isaac Dunham <idunham@lavabit.com>]

On Wed, 11 Apr 2012 22:35:20 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> > sys/vm86.h is largely a wrapper for asm/vm86.h from linux-libc-dev,
> > but provides one other function (prototype per man 2 vm86): 
> > int vm86(unsigned long fn, struct vm86plus_struct *v86);

> Hmm, I recently (essentially) rejected a request to include sys/io.h
> (legacy 16bit x86 port io) on the basis that it has no modern use and
> is machine-specific. However vm86 is a little bit different since it's
> a syscall.. and dosemu, while old and ugly, may be useful to some
> people. Xfbdev using vm86 is just broken, but since there do seem to
> be valid uses, I think this could potentially be added... and it might
> call on me to rethink the rejection of sys/io.h.

The version of Xvesa I'm dealing with also needs sys/io.h, I later
realized.  Not sure whether that's needed for Xfbdev, though.

This is the only way to access BIOS calls from Linux; unfortunately,
using the BIOS is necessary for proper screen setup/resume on some machines.  
Not sure why Xfbdev used it, but I know Xvesa uses it to call the BIOS
VGA initialization; pm-utils (standard way of handling
hibernate/suspend oddities) probably also needs this for the same
purpose, though I haven't checked that.

I also noticed that it's using __uid_t & __gid_t, which appear to be
replaced by uid_t & gid_t in musl.  It may be wrong/unportable to depend
on implementation-specific stuff (__*), but I've seen these several
times before (a LOT of stuff won't build without modification).  What's
the proper approach here? Define the old types all the time (strictly
speaking, it's in the implementation-reserved namespace), only if the
proper macros are defined, or expect people to fix the code?

Isaac Dunham