From: Oliver Falk <oliver@linux-kernel.at>
To: Linux on Alpha processors <axp-list@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Jay Estabrook <jay.estabrook@hp.com>,
ac-admin@lists.anotherbloody.com
Subject: Re: 2.6.23 alpha unistd.h changes
Date: Mon, 17 Sep 2007 22:51:13 +0200 [thread overview]
Message-ID: <46EEE8C1.5040506@linux-kernel.at> (raw)
In-Reply-To: <46EEE483.4020209@linux-kernel.at>
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
Oliver Falk schrieb:
> Hi!
>
> At Alphacore we used to patch the kernel headers for a while now; We
> added syscalls __NR_openat (447) until __NR_tee (466).
>
> However, since 2.6.23 these syscall where added upstream, but with
> different syscall numbers; What happens is the following:
>
> * glibc 2.6.90 compiled with 2.6.23 headers installed
> * kernel 2.6.21 (our patched headers in place, different syscall
> 'ordering'/numbers) installed
>
> [root@tyskie ~]# uname -r; touch x; rm -f x
> 2.6.23-0.145.rc4.fc8
> rm: cannot remove `x': File exists
>
> :-( I don't want to live without rm :-P and chmod doesn't work as well...
>
> If I start 2.6.15, where these syscalls where not in place, it works
> just fine. If I install old glibc 2.6 (compiled against 2.6.21 headers)
> and kernel 2.6.21 also everything is fine.
>
> Final test was now:
> * Boot kernel 2.6.23 and glibc 2.6.90 (compiled against 2.6.23 headers),
> also everything seems to work.
>
> As these additions are quite new to upstream kernel, but at Alphacore we
> have patched it since a while now (I don't know about other Alpha ports;
> Debian folks may speak up now!), I would suggest to use the same
> 'ordering' of the syscalls upstream and add the new syscalls that we had
> not in place, but are now upstream to the end of our 'old' list.
>
> I have attached our patch that we used for 2.6.21.
>
>
> Please let me know if that's fine everyone and keep me posted directly
> and only via m/l, as I might miss the mail then...
Attached patch should bring ordering back to what we had at AC.
systbls.S should be ordered as well, but from functional perspective, I
don't worry about that for now :-P
-of
[-- Attachment #2: unistd.h.old_syscall_ordering.patch --]
[-- Type: application/octet-stream, Size: 1753 bytes --]
--- unistd.h.old_syscall_ordering 2007-09-17 22:37:11.000000000 +0200
+++ unistd.h 2007-09-17 22:42:06.000000000 +0200
@@ -401,30 +401,30 @@
#define __NR_inotify_init 444
#define __NR_inotify_add_watch 445
#define __NR_inotify_rm_watch 446
-#define __NR_fdatasync 447
-#define __NR_kexec_load 448
-#define __NR_migrate_pages 449
-#define __NR_openat 450
-#define __NR_mkdirat 451
-#define __NR_mknodat 452
-#define __NR_fchownat 453
-#define __NR_futimesat 454
-#define __NR_fstatat64 455
-#define __NR_unlinkat 456
-#define __NR_renameat 457
-#define __NR_linkat 458
-#define __NR_symlinkat 459
-#define __NR_readlinkat 460
-#define __NR_fchmodat 461
-#define __NR_faccessat 462
-#define __NR_pselect6 463
-#define __NR_ppoll 464
-#define __NR_unshare 465
-#define __NR_set_robust_list 466
-#define __NR_get_robust_list 467
-#define __NR_splice 468
-#define __NR_sync_file_range 469
-#define __NR_tee 470
+#define __NR_openat 447
+#define __NR_mkdirat 448
+#define __NR_mknodat 449
+#define __NR_fchownat 450
+#define __NR_futimesat 451
+#define __NR_unlinkat 452
+#define __NR_renameat 453
+#define __NR_linkat 454
+#define __NR_symlinkat 455
+#define __NR_readlinkat 456
+#define __NR_fchmodat 457
+#define __NR_faccessat 458
+#define __NR_pselect6 459
+#define __NR_ppoll 460
+#define __NR_unshare 461
+#define __NR_set_robust_list 462
+#define __NR_get_robust_list 463
+#define __NR_splice 464
+#define __NR_sync_file_range 465
+#define __NR_tee 466
+#define __NR_fdatasync 467
+#define __NR_kexec_load 468
+#define __NR_migrate_pages 469
+#define __NR_fstatat64 470
#define __NR_vmsplice 471
#define __NR_move_pages 472
#define __NR_getcpu 473
next prev parent reply other threads:[~2007-09-17 20:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 20:33 2.6.23 alpha unistd.h changes Oliver Falk
2007-09-17 20:51 ` Oliver Falk [this message]
2007-09-17 21:15 ` H. Peter Anvin
2007-09-18 8:49 ` Oliver Falk
2007-09-17 21:22 ` Adrian Bunk
2007-09-18 8:54 ` Oliver Falk
2007-09-18 9:11 ` Sergey Tikhonov
2007-09-18 12:20 ` [AC-Admin] " Oliver Falk
2007-09-17 21:41 ` Adrian Bunk
2007-09-18 8:47 ` Oliver Falk
2007-09-18 14:07 ` Adrian Bunk
2007-09-18 15:44 ` Oliver Falk
2007-09-18 8:35 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46EEE8C1.5040506@linux-kernel.at \
--to=oliver@linux-kernel.at \
--cc=ac-admin@lists.anotherbloody.com \
--cc=axp-list@redhat.com \
--cc=jay.estabrook@hp.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.