Compatability: missing sys/vm86.h

Compatability: missing sys/vm86.h

[Isaac Dunham]

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);

There are no feature test macros required.

This is needed for some versions of Xvesa/Xfbdev, as well as dev86,
dosemu, and a number of other programs.

Re: Compatability: missing sys/vm86.h

[Rich Felker]

On Tue, Apr 10, 2012 at 01:00:24PM -0700, Isaac Dunham 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);
> 
> There are no feature test macros required.
> 
> This is needed for some versions of Xvesa/Xfbdev, as well as dev86,
> dosemu, and a number of other programs.

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.

Rich

Re: Compatability: missing sys/vm86.h

[Isaac Dunham]

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

Re: Compatability: missing sys/vm86.h

[Rich Felker]

On Thu, Apr 12, 2012 at 04:59:12PM -0700, Isaac Dunham wrote:
> 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.

It shouldn't be needed by Xfbdev, but last I checked (mind you this
was 5+ years ago), Xfbdev was doing all kinds of idiotic things that
made it need root for no good reason... like reprogramming the
keyboard controller to minimum repeat rate rather than respecting the
preexisting setting.

With that said, I think the arguments for including this junk, despite
it being junk, are becoming compelling, and I'll probably just go
ahead and do it.

> 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.  

This should really be fixed at the driver level (writing the correct
driver code rather than calling out to potentially-buggy/dangerous
BIOS code that might even contain trojans installed when another OS
was running and flashed the BIOS secretly), but demanding that it be
fixed is outside the scope/authority of musl... :(

> 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?

This is something I intend to stand firm on. Software using type names
in the reserved namespace is absolutely broken, has no excuse for
doing so, and needs to be fixed. Please file bug reports.

The reason glibc defines the __-prefixed type names is that,
sometimes, a header needs to prototype a function that requires an
argument of that type, or define a structure containing an element of
that type (usually a nonstandard extension element of the structure
whose name is itself __-prefixed), without exposing the name of the
type. These type names were never intended to be used by applications
whatsoever. If an application is trying to use uid_t or similar and
finding that it's not defined, that means either the application has
failed to include the right headers or define the right feature test
macros. (And since glibc defines almost everything by default when no
feature test macros are present, it almost surely just means the
application is not including the right header.) Of course, usually,
the right header has already been included and just fixing the type
name will make the application work without any further effort.

If this problem is as widespread as you say, it may be worthwhile to
write a utility that recursively runs sed on a source tree, fixing all
instances, and generates a patch to send upstream...

Rich

sed unmacro

[Isaac Dunham]

On Thu, 12 Apr 2012 20:18:51 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Thu, Apr 12, 2012 at 04:59:12PM -0700, Isaac Dunham wrote:

> > 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.  
> 
> This should really be fixed at the driver level (writing the correct
> driver code rather than calling out to potentially-buggy/dangerous
> BIOS code that might even contain trojans installed when another OS
> was running and flashed the BIOS secretly), but demanding that it be
> fixed is outside the scope/authority of musl... :(
In some cases, it may be beyond the realm of feasibility:
it seems that a number of hardware vendors are convinced that they need
their own (incompatible, of course!) VGA initialization process, so
doing it "correctly" on one laptop will get you nothing on another.
AtomBIOS does the opposite, but that's AMD only.
Unfortunately, we're stuck working with the hardware that we get, not
hardware done properly.
 
> > 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).
 
> This is something I intend to stand firm on. Software using type names
> in the reserved namespace is absolutely broken, has no excuse for
> doing so, and needs to be fixed. Please file bug reports.
..
> If this problem is as widespread as you say, it may be worthwhile to
> write a utility that recursively runs sed on a source tree, fixing all
> instances, and generates a patch to send upstream...

Doesn't run recursively or generate a patch, but... 

sed -e 's/__\([ug]id_t\)/\1/g' \
 -e 's/__long_double_t/long\ double/g' \
 -e 's/__BEGIN_DECLS/#ifdef\ __cplusplus\nextern\ \"C\"\ {\n#endif/g' \
 -e 's/__END_DECLS/#ifdef\ __cplusplus\n}\n#endif/g' 

makes a number of changes that are commonly needed.

And in case of macros like __P() (from sys/compat.h):

sed -e 's/__PM\{,1\}T\{,1\}(\(.*\))/\1/g' \
 -e 's/__NTH(\(.*\))/\1/g' \
 -e 's/__STRING(\(.*\))/#\1/g' 

This part is not as foolsafe--it fails on more complicated stuff like 
__STRING(somestring); sin(x);