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.