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
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
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
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
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
Oliver Falk <[email protected]> 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
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
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
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
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
[email protected]
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
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
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