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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox