[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120413001851.GG7281@brightrain.aerifal.cx>
Date: Thu, 12 Apr 2012 20:18:51 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Compatability: missing sys/vm86.h
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
