2.6.23 alpha unistd.h changes

2.6.23 alpha unistd.h changes

[Oliver Falk]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

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...

Best,
 Oliver

[-- Attachment #2: linux-2.6.21-alpha_missing_syscalls.patch --]
[-- Type: application/octet-stream, Size: 2000 bytes --]

--- linux-2.6.21/include/asm-alpha/unistd.h.missing_defines	2007-05-16 10:53:02.000000000 +0200
+++ linux-2.6.21/include/asm-alpha/unistd.h	2007-05-16 10:54:44.000000000 +0200
@@ -388,9 +388,30 @@
 #define __NR_inotify_add_watch		445
 #define __NR_inotify_rm_watch		446
 
+#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
+
 #ifdef __KERNEL__
 
-#define NR_SYSCALLS			447
+#define NR_SYSCALLS			467
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
--- linux-2.6.21/arch/alpha/kernel/systbls.S.missing_defines	2007-05-16 11:32:29.000000000 +0200
+++ linux-2.6.21/arch/alpha/kernel/systbls.S	2007-05-16 11:30:36.000000000 +0200
@@ -465,6 +465,26 @@
 	.quad sys_inotify_init
 	.quad sys_inotify_add_watch		/* 445 */
 	.quad sys_inotify_rm_watch
+	.quad sys_openat
+	.quad sys_mkdirat
+	.quad sys_mknodat
+	.quad sys_fchownat			/* 450 */
+	.quad sys_futimesat
+	.quad sys_unlinkat
+	.quad sys_renameat
+	.quad sys_linkat
+	.quad sys_symlinkat			/* 455 */
+	.quad sys_readlinkat
+	.quad sys_fchmodat
+	.quad sys_faccessat
+	.quad sys_pselect6
+	.quad sys_ppoll				/* 460 */
+	.quad sys_unshare
+	.quad sys_set_robust_list
+	.quad sys_get_robust_list
+	.quad sys_splice
+	.quad sys_sync_file_range
+	.quad sys_tee
 
 	.size sys_call_table, . - sys_call_table
 	.type sys_call_table, @object

Re: 2.6.23 alpha unistd.h changes

[Oliver Falk]

[-- 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

Re: 2.6.23 alpha unistd.h changes

[H. Peter Anvin]

Oliver Falk wrote:
> 
> 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.
> 

If you want to avoid that in the future, you may want to push your
changes upstream.

	-hpa

Re: 2.6.23 alpha unistd.h changes

[Adrian Bunk]

On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
> Hi!

Hi Oliver!

> At Alphacore we used to patch the kernel headers for a while now; We
> added syscalls __NR_openat (447) until __NR_tee (466).

Why did your numbers differ from the numbers that were used in the 
upstream kernel?

The Alpha maintainers (Cc's added) might now better what happened here.

> However, since 2.6.23 these syscall where added upstream, but with
> different syscall numbers; What happens is the following:
>...

These syscalls were added in 2.6.22, not 2.6.23, and are therefore in 
the officially released kernel since more than two months.

Changing a userspace ABI that has already been part of an officially 
released kernel because someone patched other syscall numbers into his 
private kernel doesn't sound like a good solution.

> Best,
>  Oliver

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.23 alpha unistd.h changes

[Adrian Bunk]

On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
> Hi!

Hi Oliver!

>...
> 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 just checked:

It seems Debian didn't patch them into the kernel at all, and since two 
months Debian unstable ships kernel 2.6.22 with the upstream syscall 
numbers.

> Best,
>  Oliver

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.23 alpha unistd.h changes

[Andi Kleen]

Oliver Falk <oliver@linux-kernel.at> writes:

> 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...

It's all your own fault. Only mainline can assign syscall numbers.
See it as a learning experience. Next time when you assign them
you shouldn't use them before the patch has reached mainline.

-Andi

Re: 2.6.23 alpha unistd.h changes

[Oliver Falk]

On 09/17/2007 11:41 PM, Adrian Bunk wrote:
> On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
>> Hi!
> 
> Hi Oliver!
> 
>> ...
>> 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 just checked:
> 
> It seems Debian didn't patch them into the kernel at all, and since two 
> months Debian unstable ships kernel 2.6.22 with the upstream syscall 
> numbers.

That's possible a problem. Right. Someone with contacts to Debian here?
If Debian hasn't rebuilt glibc against the new headers, we could change
it without problems.

If not, we have a problem on AC... Anyone with a glibc that was compiled
against our patched unistd.h (so including the new syscall numbers),
will not be able to upgrade the kernel, but also needs to upgrade glibc
and then *must* reboot :-(

Best,
 Oliver

Re: 2.6.23 alpha unistd.h changes

[Oliver Falk]

On 09/17/2007 11:15 PM, H. Peter Anvin wrote:
> Oliver Falk wrote:
>> 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.
>>
> 
> If you want to avoid that in the future, you may want to push your
> changes upstream.

Sure, sure! I wasn't the one who actually did patch that, I just took
what was there...

I'll will submit any relevant patches to upstream from now on!

Best,
 Oliver

Re: 2.6.23 alpha unistd.h changes

[Oliver Falk]

On 09/17/2007 11:22 PM, Adrian Bunk wrote:
> On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
>> At Alphacore we used to patch the kernel headers for a while now; We
>> added syscalls __NR_openat (447) until __NR_tee (466).
> 
> Why did your numbers differ from the numbers that were used in the 
> upstream kernel?

Afaik, our patch was done a while ago and nobody every submitted it
upstream - don't know why...

At AC, we follow RH/Fedora packages and there we had glibc-kernheaders -
where our patch originates. When the glibc/kernel packages changed and
glibc-kernheaders died, I patched the syscalls into kernel headers; Not
thinking that I better submit it upstream. :-(

> The Alpha maintainers (Cc's added) might now better what happened here.
> 
>> However, since 2.6.23 these syscall where added upstream, but with
>> different syscall numbers; What happens is the following:
>> ...
> 
> These syscalls were added in 2.6.22, not 2.6.23, and are therefore in 
> the officially released kernel since more than two months.

Yes, 2.6.22, I've just encountered the problem with 2.6.23...

> Changing a userspace ABI that has already been part of an officially 
> released kernel because someone patched other syscall numbers into his 
> private kernel doesn't sound like a good solution.

As I wrote in my previous mail, that's true, but if Debian folks haven't
recompiled glibc against the new headers we can change it without
breaking something...

-of

Re: 2.6.23 alpha unistd.h changes

[Sergey Tikhonov]

Oliver Falk wrote:
> On 09/17/2007 11:22 PM, Adrian Bunk wrote:
>   
>> On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
>>     
>>> At Alphacore we used to patch the kernel headers for a while now; We
>>> added syscalls __NR_openat (447) until __NR_tee (466).
>>>       
>> Why did your numbers differ from the numbers that were used in the 
>> upstream kernel?
>>     
>
> Afaik, our patch was done a while ago and nobody every submitted it
> upstream - don't know why...
>   
Yes, it was done by me and I had no info how to push the updates to 
upstream, sorry. (by that time,
there were no latest "distribution" available with those changes).
> At AC, we follow RH/Fedora packages and there we had glibc-kernheaders -
> where our patch originates. When the glibc/kernel packages changed and
> glibc-kernheaders died, I patched the syscalls into kernel headers; Not
> thinking that I better submit it upstream. :-(
>   
Yea, now there is more interest and it is better to do it right. :)

Regards,

-- 
Sergey Tikhonov

Head, R&D department
Solvo Ltd.
Saint-Petersburg, Russia
http://www.solvo.ru
tsv@solvo.ru

Re: [AC-Admin] Re: 2.6.23 alpha unistd.h changes

[Oliver Falk]

On 09/18/2007 11:11 AM, Sergey Tikhonov wrote:
> Oliver Falk wrote:
>> On 09/17/2007 11:22 PM, Adrian Bunk wrote:
>>  
>>> On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
>>>    
>>>> At Alphacore we used to patch the kernel headers for a while now; We
>>>> added syscalls __NR_openat (447) until __NR_tee (466).
>>>>       
>>> Why did your numbers differ from the numbers that were used in the
>>> upstream kernel?
>>>     
>>
>> Afaik, our patch was done a while ago and nobody every submitted it
>> upstream - don't know why...
>>   
> Yes, it was done by me and I had no info how to push the updates to
> upstream, sorry. (by that time,
> there were no latest "distribution" available with those changes).
>> At AC, we follow RH/Fedora packages and there we had glibc-kernheaders -
>> where our patch originates. When the glibc/kernel packages changed and
>> glibc-kernheaders died, I patched the syscalls into kernel headers; Not
>> thinking that I better submit it upstream. :-(
>>   
> Yea, now there is more interest and it is better to do it right. :)

To make it easy for everyone....

There should not be many AC users that run the latest versions of
everything.

I will keep the sorting of the syscalls as they are - no change required
upstream.

People who want new kernel or new glibc will then also need to update
the other. DOT. POINT. END. :-)

Kernel 2.6.23 will also require new aboot.... So many things....

Since online upgrading from AC3 to FC8axp will not be supported anyway
(because of various reasons and now 2 more of them), I can live with
that decision finally.

Thx everyone...

Best,
 Oliver

Re: 2.6.23 alpha unistd.h changes

[Adrian Bunk]

On Tue, Sep 18, 2007 at 10:47:31AM +0200, Oliver Falk wrote:
> On 09/17/2007 11:41 PM, Adrian Bunk wrote:
> > On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
> >> Hi!
> > 
> > Hi Oliver!
> > 
> >> ...
> >> 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 just checked:
> > 
> > It seems Debian didn't patch them into the kernel at all, and since two 
> > months Debian unstable ships kernel 2.6.22 with the upstream syscall 
> > numbers.
> 
> That's possible a problem. Right. Someone with contacts to Debian here?
> If Debian hasn't rebuilt glibc against the new headers, we could change
> it without problems.
>...

According to the Debian auto-builder database [1], the Alpha glibc 
package in Debian unstable has been rebuilt 8 times since the 2.6.22 
kernel packages entered Debian unstable.

And it's not only Debian, at least Gentoo also offers an Alpha port.

> Best,
>  Oliver

cu
Adrian

[1] http://buildd.debian.org/build.php?arch=alpha&pkg=glibc

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.23 alpha unistd.h changes

[Oliver Falk]

On 09/18/2007 04:07 PM, Adrian Bunk wrote:
> On Tue, Sep 18, 2007 at 10:47:31AM +0200, Oliver Falk wrote:
>> On 09/17/2007 11:41 PM, Adrian Bunk wrote:
>>> On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote:
>>>> Hi!
>>> Hi Oliver!
>>>
>>>> ...
>>>> 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 just checked:
>>>
>>> It seems Debian didn't patch them into the kernel at all, and since two 
>>> months Debian unstable ships kernel 2.6.22 with the upstream syscall 
>>> numbers.
>> That's possible a problem. Right. Someone with contacts to Debian here?
>> If Debian hasn't rebuilt glibc against the new headers, we could change
>> it without problems.
>> ...
> 
> According to the Debian auto-builder database [1], the Alpha glibc 
> package in Debian unstable has been rebuilt 8 times since the 2.6.22 
> kernel packages entered Debian unstable.
> 
> And it's not only Debian, at least Gentoo also offers an Alpha port.

Well. As I said. I'll step back and let it be as it is. Debian was to
fast. :-)

-of