public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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