[gentoo-releng] 2006.0? nptl?

[gentoo-releng] 2006.0? nptl?

[Chris Gianelloni]

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

So... What do we say to going nptl across the board for 2006.0 on every
platform that supports 2.6 headers?  This would, of course, require
approval from each arch team, but I'm sure ppc and amd64 are chomping at
the bits for this one, and it sounds like the x86 arch team is wanting
it also.

So... any comments?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2006.0? nptl?

[solar]

On Fri, 2005-09-16 at 08:35 -0400, Chris Gianelloni wrote:
> So... What do we say to going nptl across the board for 2006.0 on every
> platform that supports 2.6 headers?  This would, of course, require
> approval from each arch team, but I'm sure ppc and amd64 are chomping at
> the bits for this one, and it sounds like the x86 arch team is wanting
> it also.

ppc32 - has problems with nptl when not using linuxthreads (oddly it
works with ASLR in place however).

x86 - sometimes has problems with *some* clients and the RTLD. 
Seems to be a problem with ld.so paths and having intermixed 
nptl/shared/static handling but I'm not sure. I have had nothing but 
success on x86 with it, but others seem to.

amd64 - Seems to support it well.

mips, sparc, ia64, m68k, arm - (don't know)

Sadly we don't really have any NPTL guru's (know of any?) that are able
to quickly fix nptl bugs so they just keep piling up in bugzilla.

There remain outstanding bugs with nptl problems.

http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=nptl&field0-0-1=component&type0-0-1=substring&value0-0-1=nptl&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=nptl&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=nptl

uclibc-* does not support nptl yet.

To me it would seem the ideal time to make the switch to NPTL is when
the toolchain is gcc-4.x/glibc-2.3.6 are doing it by default and in
stable.

-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2006.0? nptl?

[Chris Gianelloni]

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

On Fri, 2005-09-16 at 09:42 -0400, solar wrote:
> On Fri, 2005-09-16 at 08:35 -0400, Chris Gianelloni wrote:
> > So... What do we say to going nptl across the board for 2006.0 on every
> > platform that supports 2.6 headers?  This would, of course, require
> > approval from each arch team, but I'm sure ppc and amd64 are chomping at
> > the bits for this one, and it sounds like the x86 arch team is wanting
> > it also.
> 
> ppc32 - has problems with nptl when not using linuxthreads (oddly it
> works with ASLR in place however).
> 
> x86 - sometimes has problems with *some* clients and the RTLD. 
> Seems to be a problem with ld.so paths and having intermixed 
> nptl/shared/static handling but I'm not sure. I have had nothing but 
> success on x86 with it, but others seem to.
> 
> amd64 - Seems to support it well.
> 
> mips, sparc, ia64, m68k, arm - (don't know)
> 
> Sadly we don't really have any NPTL guru's (know of any?) that are able
> to quickly fix nptl bugs so they just keep piling up in bugzilla.
> 
> There remain outstanding bugs with nptl problems.
> 
> http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=nptl&field0-0-1=component&type0-0-1=substring&value0-0-1=nptl&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=nptl&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=nptl
> 
> uclibc-* does not support nptl yet.
> 
> To me it would seem the ideal time to make the switch to NPTL is when
> the toolchain is gcc-4.x/glibc-2.3.6 are doing it by default and in
> stable.

This actually stems from a discussion on #gentoo-x86 where Azarah was
discussing how we need to switch to nptl for default specifically for
gcc-4.x/glibc-2.3.6 to be able to go stable.  I'm just trying to get a
conversation going here on what pitfalls we might run across on various
platforms and if we're ready to make that plunge.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2006.0? nptl?

[Jason Wever]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Sep 2005, Chris Gianelloni wrote:

> So... What do we say to going nptl across the board for 2006.0 on every
> platform that supports 2.6 headers?  This would, of course, require
> approval from each arch team, but I'm sure ppc and amd64 are chomping at
> the bits for this one, and it sounds like the x86 arch team is wanting
> it also.
>
> So... any comments?

Even once we get 2.6 headers in an non-development profile, nptl is not 
currently working on SPARC in glibc.

Cheers,
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDKtRNdKvgdVioq28RApdiAJ9p5x8YaHEywY2ZV7U3yxdlcJAtdQCeNflH
kFqOAwXLmkiuBQ2Kl5pl8t8=
=9K9t
-----END PGP SIGNATURE-----
-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2006.0? nptl?

[Daniel Ostrow]

On Fri, 2005-09-16 at 10:16 -0400, Chris Gianelloni wrote:
> On Fri, 2005-09-16 at 09:42 -0400, solar wrote:
> > On Fri, 2005-09-16 at 08:35 -0400, Chris Gianelloni wrote:
> > > So... What do we say to going nptl across the board for 2006.0 on every
> > > platform that supports 2.6 headers?  This would, of course, require
> > > approval from each arch team, but I'm sure ppc and amd64 are chomping at
> > > the bits for this one, and it sounds like the x86 arch team is wanting
> > > it also.
> > 
> > ppc32 - has problems with nptl when not using linuxthreads (oddly it
> > works with ASLR in place however).
> > 
> > x86 - sometimes has problems with *some* clients and the RTLD. 
> > Seems to be a problem with ld.so paths and having intermixed 
> > nptl/shared/static handling but I'm not sure. I have had nothing but 
> > success on x86 with it, but others seem to.
> > 
> > amd64 - Seems to support it well.
> > 
> > mips, sparc, ia64, m68k, arm - (don't know)
> > 

Speaking only for ppc64 we have been running nptl or nptlonly systems
for a good while now and *almost* took the plunge to make it the default
in 2005.1. For us this would be a welcome change.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2006.0? nptl?

[Chris Gianelloni]

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

On Fri, 2005-09-16 at 08:18 -0600, Jason Wever wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 16 Sep 2005, Chris Gianelloni wrote:
> 
> > So... What do we say to going nptl across the board for 2006.0 on every
> > platform that supports 2.6 headers?  This would, of course, require
> > approval from each arch team, but I'm sure ppc and amd64 are chomping at
> > the bits for this one, and it sounds like the x86 arch team is wanting
> > it also.
> >
> > So... any comments?
> 
> Even once we get 2.6 headers in an non-development profile, nptl is not 
> currently working on SPARC in glibc.

As with the "2.6 kernels as default" decision, we would of course make
exceptions for any architecture/platform that is not deemed stable by
that architecture team.  We don't want to cause headaches, just get to
nptl where we can.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2006.0? nptl?

[kloeri]

On Fri, Sep 16, 2005 at 10:30:01AM -0400, Chris Gianelloni wrote:
> 
> As with the "2.6 kernels as default" decision, we would of course make
> exceptions for any architecture/platform that is not deemed stable by
> that architecture team.  We don't want to cause headaches, just get to
> nptl where we can.
> 
Alpha may or may not be ready. I only unmasked nptl on alpha yesterday
but I've gotten lots of succes reports from users. Other distributions
seems to do fine with NPTL on Alpha as well so I'm not expecting any
major issues unless the kernel people decides to randomly break nptl ;p

Regards,
Bryan Østergaard

-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2006.0? nptl?

[Kumba]

solar wrote:

> mips,

This is happening, but we would need to make a major leap forward on some 
packages.  We'd need at bare minimum, gcc-4.1 CVS HEAD, glibc CVS HEAD, and 
binutils CVS HEAD just to even get the compiler base built.  considering we're 
still on 3.4.4, I don't see this happening for awhile.

geoman's been working on a gcc-4 userland, and has been finding some solutions 
around some rather annoying bugs, like a librt patch we copied from debian back 
in 2003 that came back and bit us, as well as some studies of a new -msym32 flag 
to replace out o64 hacks in IP22/IP32 kernels.

We also use a patch for gcc-3.4.4 that adds optimization (-march/-mtune) support 
for the R10000 processors that hasn't been ported to gcc-4 or carried upstream. 
  Every attempt I've made to get some gcc-hacker to port it (it's only 12kb), I 
either get no response or a link to the gcc info manual on compiler internals.

Once these are fixed, then there's the fun part of actually testing everything. 
  On two ABIs (o32/n32) as well.  And n32 is kind of stuck in the mud again due 
to an undiscovered pthreads bug that h0rks our glib package, making a userland a 
bit impractical.

Safely stated, I think we're gonna be in linuxthreads-land for a wee bit longer :)


> sparc,

I have this running on my Blade 100, and it seems to work well, even with 
glibc-2.3.5 in portage.  Weeve probably has better info on its support, though.



--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-releng@gentoo.org mailing list