Displaying 7 results from an estimated 7 matches for "__nr_openat".
Did you mean:
__nr_open
2006 Feb 19
0
[patch] openat build with older !openat linux tree
klibc/arch/i386/openat.o: In function `openat':klibc/arch/i386/openat.S:19: undefined reference to `__NR_openat'
make[3]: *** [klibc/libc.so] Error 1
belows allows to build against a tree based on 2.6.15
Signed-off-by: maximilian attems <maks@sternwelten.at>
diff --git a/klibc/arch/i386/openat.S b/klibc/arch/i386/openat.S
index 3955eae..40ab299 100644
--- a/klibc/arch/i386/openat.S
+++ b/klibc/a...
2012 Jan 29
5
[PATCH 0/2 v3] mkstemp() and m68k support
Hi,
after a year, I decided to hack on klibc again. I?ve reworked
both the patch to add mkstemp(), discussing to use AT_RANDOM
as cheap entropy source on IRC (if there will ever be another
entropy consumer, I can quickly write a minimal arc4random()
seeded from it, as it has only 16 octets), capable of making
a working mksh (static and shared) on amd64/xen, and the m68k
support code, leading to
2012 May 15
5
[PATCH 0/5] resubmitting pending patches
Hi,
I?ve gone through the mailing list archives and hereby want
to resubmit my pending patches. Most are independent of each
other, except the m68k patch which will only be complete if
sigsuspend is also fixed. (It can be applied before that,
though.)
http://www.zytor.com/pipermail/klibc/2012-January/003173.html
[PATCH] fix m68k support
Resubmitted here as 0005. While there was a question from
2018 Mar 19
0
get_user_pages returning 0 (was Re: kernel BUG at drivers/vhost/vhost.c:LINE!)
...CE
#include <endian.h>
#include <stdint.h>
#include <string.h>
#include <sys/syscall.h>
#include <unistd.h>
uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff};
void loop()
{
long res;
memcpy((void*)0x202ac000, "/dev/vhost-net", 15);
res = syscall(__NR_openat, 0xffffffffffffff9c, 0x202ac000, 2, 0);
if (res != -1)
r[0] = res;
*(uint64_t*)0x20000040 = 0;
syscall(__NR_ioctl, r[0], 0x40000000af01, 0x20000040);
memcpy((void*)0x20000180, "/dev/audio", 11);
res = syscall(__NR_openat, 0xffffffffffffff9c, 0x20000180, 0, 0);
if (res != -...
2011 Jan 29
2
another bugfix
Hi,
number three, where I first thought it was a GCC bug but is
apparently bad code in klibc. Submitted with permission:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533#c6
Patch attached again (sorry) not just because that is easier
with my mail system but also to keep original author intact.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine f?r den einzig
>
2006 Jun 26
0
[klibc 24/43] i386 support for klibc
...() system call - oddball due to the varadic
+ * prototype, which forces the use of the cdecl calling convention,
+ * and the need for O_LARGEFILE.
+ */
+
+#include <asm/unistd.h>
+
+/* <asm/fcntl.h>, despite the name, isn't assembly-safe */
+#define O_LARGEFILE 0100000
+
+#ifdef __NR_openat /* Don't build if kernel headers too old */
+
+ .globl openat
+ .type openat, at function
+
+openat:
+ orl $O_LARGEFILE,12(%esp)
+ pushl $__NR_openat
+ jmp __syscall_varadic
+
+ .size openat,.-openat
+
+#endif
diff --git a/usr/klibc/arch/i386/setjmp.S b/usr/klibc/arch/i386/setjmp.S
new file mo...
2006 Jun 28
35
[klibc 00/31] klibc as a historyless patchset (updated and reorganized)
I have updated the klibc patchset based on feedback received. In
particular, the patchset has been reorganized so as not to break
git-bisect.
Additionally, this updates the patch base to 2.6.17-git12
(d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main
difference on the klibc side is removal of obsolete code.
This is also available as a git tree at: