2.6.23 alpha unistd.h changes

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

[roottyskie ~]# 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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list

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
> 
> [roottyskie ~]# 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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list

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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list

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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list

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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list

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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list

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

_______________________________________________
axp-list mailing list
axp-listredhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list