All of lore.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 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.