* Compatability: missing sys/vm86.h @ 2012-04-10 20:00 Isaac Dunham 2012-04-12 2:35 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Isaac Dunham @ 2012-04-10 20:00 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatability: missing sys/vm86.h 2012-04-10 20:00 Compatability: missing sys/vm86.h Isaac Dunham @ 2012-04-12 2:35 ` Rich Felker 2012-04-12 23:59 ` Isaac Dunham 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2012-04-12 2:35 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatability: missing sys/vm86.h 2012-04-12 2:35 ` Rich Felker @ 2012-04-12 23:59 ` Isaac Dunham 2012-04-13 0:18 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Isaac Dunham @ 2012-04-12 23:59 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatability: missing sys/vm86.h 2012-04-12 23:59 ` Isaac Dunham @ 2012-04-13 0:18 ` Rich Felker 2012-04-13 2:45 ` sed unmacro Isaac Dunham 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2012-04-13 0:18 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* sed unmacro 2012-04-13 0:18 ` Rich Felker @ 2012-04-13 2:45 ` Isaac Dunham 0 siblings, 0 replies; 5+ messages in thread From: Isaac Dunham @ 2012-04-13 2:45 UTC (permalink / raw) To: musl 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); ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-04-13 2:45 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-10 20:00 Compatability: missing sys/vm86.h Isaac Dunham 2012-04-12 2:35 ` Rich Felker 2012-04-12 23:59 ` Isaac Dunham 2012-04-13 0:18 ` Rich Felker 2012-04-13 2:45 ` sed unmacro Isaac Dunham
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).