mailing list of musl libc
 help / color / mirror / code / Atom feed
* [PATCH 1/10] ioperm & iopl
@ 2012-07-23  1:13 Isaac Dunham
  2012-07-23  1:17 ` [PATCH 2/10] splice Isaac Dunham
                   ` (9 more replies)
  0 siblings, 10 replies; 30+ messages in thread
From: Isaac Dunham @ 2012-07-23  1:13 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

This patch series is basically a reworked version of orc's previous
patch.
From what orc said, the first patch should provide enough to build
Xorg; I haven't tested this yet.
A few more patches are syscall wrappers (splice) or trivial
functions (finite).
Finally, there are several aliases.

With that, I'm sending the first patch.
This adds ioperm & iopl along with io.h, though a full io.h has
several more syscalls.

Isaac Dunham 

[-- Attachment #2: 1-ioperm-iopl.diff --]
[-- Type: text/x-patch, Size: 738 bytes --]

diff --git a/include/sys/io.h b/include/sys/io.h
new file mode 100644
index 0000000..1f4d1a3
--- /dev/null
+++ b/include/sys/io.h
@@ -0,0 +1,2 @@
+int ioperm(unsigned long, unsigned long, int);
+int iopl(int);
diff --git a/src/linux/ioperm.c b/src/linux/ioperm.c
new file mode 100644
index 0000000..6d6d383
--- /dev/null
+++ b/src/linux/ioperm.c
@@ -0,0 +1,6 @@
+#include "syscall.h"
+
+int ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+	return syscall(SYS_ioperm, from, num, turn_on);
+}
diff --git a/src/linux/iopl.c b/src/linux/iopl.c
new file mode 100644
index 0000000..7fc9102
--- /dev/null
+++ b/src/linux/iopl.c
@@ -0,0 +1,6 @@
+#include "syscall.h"
+
+int iopl(int level)
+{
+	return syscall(SYS_iopl, level);
+}

^ permalink raw reply	[flat|nested] 30+ messages in thread
* Re: [PATCH 9/10] GLIBC ABI patches
@ 2012-07-25  3:00 idunham
  2012-07-25 15:06 ` Rich Felker
  0 siblings, 1 reply; 30+ messages in thread
From: idunham @ 2012-07-25  3:00 UTC (permalink / raw)
  To: musl

>
>>>>>>> Just nonsense aliases GNU uses...
>>>>>>> Needed for ABI compatability.
>>>>>> could we mark them as such? at least with a comment.
>>>>>> I really like that musl is so readable. This patch adds some
>>>>>> obfuscation that can simply be countered by marking it as "ok this
>>>>>> is only here for reason X."
>>>>> I would like to see those options behind a compile time option : It
>>>>> bloats musl with in many cases unneeded code. I test my compiles with
>>>>> musl, and I like it lean and mean.
>>>> These are just aliases, not code. There's no bloat there.
>>>>
>>>> One of the advantages of musl is its LACK of configurability: If you
>>>> have *musl*, you know what precisely you're getting.
>>>>
>>>> With valediction,
>>>> - Gregor Richards
>>>>
>>> While I agree with the above, I still have a few objections :
>>>
>>> - We don't want glibc compatibility. We want a good libc.
>>> - That we even need those aliases is usually a case of bad automake /
>>> autoconf / bad feature detection.
>>>
>>> Why bloat code with stuff to provide glibc compatibility ?
>>>
>>>
>>> 	Igmar
>>
>> These are for ABI compatibility, not API compatibility. Nobody using
>> glibc uses these symbols intentionally, they are renamed and aliased by
>> the library. Last I checked, musl is shockingly close to ABI
>> compatibility with glibc, and like it or not, that's a valuable feature.
>> If you don't like the *bloat* of it, you'll have to dig out a lot of the
>> existing aliases too.
>
> I've seen lots of code who use internal glibc functions / data structures.
> We want to prevent them from being used, that's why I personally have a
> problem with adding code like this. Unless it actually serves a real use.
>
> 	Igmar

The real use here, from what orc was saying, is running the proprietary
nvidia driver on a musl-based system.

Rich:
I have three questions:

1. Should it be possible to weak_alias an externally defined function?
ie, src/stdlib/strtod.c defines strtod, then src/glibc-abi/stdlib.c goes:
#include "libc.h"
#include <stdlib.h>
weak_alias(strtod, __strtod_internal)
2. Would this result in obfustication of the source?
3. Would a subdirectory of src/ solely for glibc ABI/API compatability be
appropriate?
The point would be to allow removing gnuish extensions without too much
trouble.
Even if 1 or 2 mean that weak_alias stuff goes in the same file, this
could contain functions like the ones added for gnulib (src/stdio/ext*.c).

Isaac Dunham




^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2012-08-07  3:29 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-23  1:13 [PATCH 1/10] ioperm & iopl Isaac Dunham
2012-07-23  1:17 ` [PATCH 2/10] splice Isaac Dunham
2012-07-23  1:21 ` [PATCH 3/10] xattr syscalls Isaac Dunham
2012-07-24 18:06   ` orc
2012-07-23  1:24 ` [PATCH 4/10] pipe2 Isaac Dunham
2012-07-23  1:28 ` [PATCH 5/10] __sigsetjmp alias Isaac Dunham
2012-07-23  1:32 ` [PATCH 6/10] Provide private versions of locale/ functions Isaac Dunham
2012-07-23  1:33 ` [PATCH 7/10] __fcntl Isaac Dunham
2012-07-23  1:36 ` [PATCH 8/10] finite Isaac Dunham
2012-07-23  7:58   ` Szabolcs Nagy
2012-07-23  1:38 ` [PATCH 9/10] GLIBC ABI patches Isaac Dunham
2012-07-23 15:11   ` Arvid E. Picciani
2012-07-24 18:15     ` Igmar Palsenberg
2012-07-24 18:19       ` Gregor Richards
2012-07-24 18:23         ` Igmar Palsenberg
2012-07-24 18:29           ` Gregor Richards
2012-07-24 18:33             ` Igmar Palsenberg
2012-07-24 23:18               ` Rich Felker
2012-07-25  7:27               ` Arvid E. Picciani
2012-07-25 14:12   ` Luca Barbato
2012-07-25 15:19     ` Rich Felker
2012-07-25 15:52       ` Luca Barbato
2012-07-25 17:35         ` Rich Felker
2012-07-25 23:06       ` idunham
2012-07-23  1:40 ` [PATCH 10/10] More glibc ABI compatability Isaac Dunham
2012-08-07  2:22 ` [PATCH 1/10] ioperm & iopl Isaac Dunham
2012-08-07  3:29   ` Isaac Dunham
2012-07-25  3:00 [PATCH 9/10] GLIBC ABI patches idunham
2012-07-25 15:06 ` Rich Felker
2012-07-25 22:19   ` Luca Barbato

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