Re: NTPL transition

Re: NTPL transition

[Carlos O'Donell]

On Thu, Sep 4, 2008 at 7:45 AM, Domenico Andreoli <cavok@dandreoli.com> wrote:
>  I would set NPTL transition as a goal for queeze.
>
> Are we available to agree on a shared path to push new life to this port?
> I mean, this issue will bite more and more frequently, it must be fixed.

I agree. I'm available and willing. I'm just not a DD nor am I
familiar with debians sbuild or buildds.

> I am available to follow the required steps but obviously the more eyes
> the better. This is the first time I work on a big transition like this.

I'm available at OFTC on #debian-glibc. I act as a debian-hppa porter
and help Aurelian when glibc hppa issues arise.

> I think the first packages have to be cross-built, until a minimal
> build system is ready to run on the new libc6.1 (chroot?). Then start
> an archive rebuild. It looks easy, where is the trap? :)

I'm not familiar with the debian build infrastructure, but I am *very*
familiar with libc since I'm the upstream ports maintainer for hppa.

I don't think there is any trap.

Cheers,
Carlos.

Re: NTPL transition

[dann frazier]

On Thu, Sep 04, 2008 at 10:13:15AM -0400, Carlos O'Donell wrote:
> On Thu, Sep 4, 2008 at 7:45 AM, Domenico Andreoli <cavok@dandreoli.com> wrote:
> >  I would set NPTL transition as a goal for queeze.
> >
> > Are we available to agree on a shared path to push new life to this port?
> > I mean, this issue will bite more and more frequently, it must be fixed.
> 
> I agree. I'm available and willing. I'm just not a DD nor am I
> familiar with debians sbuild or buildds.
> 
> > I am available to follow the required steps but obviously the more eyes
> > the better. This is the first time I work on a big transition like this.
> 
> I'm available at OFTC on #debian-glibc. I act as a debian-hppa porter
> and help Aurelian when glibc hppa issues arise.
> 
> > I think the first packages have to be cross-built, until a minimal
> > build system is ready to run on the new libc6.1 (chroot?). Then start
> > an archive rebuild. It looks easy, where is the trap? :)
> 
> I'm not familiar with the debian build infrastructure, but I am *very*
> familiar with libc since I'm the upstream ports maintainer for hppa.
> 
> I don't think there is any trap.

I've already done the initial bootstrapping and John Wright and I have
a buildd actively rebuilding bits against sid. We're rsyncing the
results out to here:
  http://parisc-linux.org/~dannf/hppa-nptl-mirror/unstable/

Suffice to say, the rebuild is going fairly smoothly. But, I wonder
how we're going to transition systems over to an NPTL userspace. Does
anyone have a plan for that?

-- 
dann frazier

Re: NTPL transition

[Carlos O'Donell]

On Thu, Sep 4, 2008 at 11:23 AM, dann frazier <dannf@dannf.org> wrote:
> I've already done the initial bootstrapping and John Wright and I have
> a buildd actively rebuilding bits against sid. We're rsyncing the
> results out to here:
>  http://parisc-linux.org/~dannf/hppa-nptl-mirror/unstable/
>
> Suffice to say, the rebuild is going fairly smoothly. But, I wonder
> how we're going to transition systems over to an NPTL userspace. Does
> anyone have a plan for that?

Isn't this the responsibility of the package manager?

Why wouldn't apt-get dist-upgrade work?

Cheers,
Carlos.

Re: NTPL transition

[dann frazier]

On Thu, Sep 04, 2008 at 11:31:52AM -0400, Carlos O'Donell wrote:
> On Thu, Sep 4, 2008 at 11:23 AM, dann frazier <dannf@dannf.org> wrote:
> > I've already done the initial bootstrapping and John Wright and I have
> > a buildd actively rebuilding bits against sid. We're rsyncing the
> > results out to here:
> >  http://parisc-linux.org/~dannf/hppa-nptl-mirror/unstable/
> >
> > Suffice to say, the rebuild is going fairly smoothly. But, I wonder
> > how we're going to transition systems over to an NPTL userspace. Does
> > anyone have a plan for that?
> 
> Isn't this the responsibility of the package manager?
> 
> Why wouldn't apt-get dist-upgrade work?

We had a discussion about this on IRC, a while back, let me see if I
can recap...

If we continue to use libc6 as the package name as we're currently
doing, at some point libc will get upgraded to the NPTL interface and
things will start crashing immediately. I asked if we could just do
"whatever x86 did", and kyle said that we have a problem they didn't -
our data nptl/lt data structures are incompatible.

We can deal with that to an extent by adding a second libc package,
e.g., libc6.1. But, jejb pointed out that, since most libs depend on
libc, we'll need to be able to have libs for both interfaces at the
same time to support a transitional upgrade - and that implies an
SONAME bump for every C library.

Hopefully there's an easier way, but I don't know of one.

-- 
dann frazier

Re: NTPL transition

[Carlos O'Donell]

On Thu, Sep 4, 2008 at 12:04 PM, dann frazier <dannf@dannf.org> wrote:
> If we continue to use libc6 as the package name as we're currently
> doing, at some point libc will get upgraded to the NPTL interface and
> things will start crashing immediately. I asked if we could just do
> "whatever x86 did", and kyle said that we have a problem they didn't -
> our data nptl/lt data structures are incompatible.
>
> We can deal with that to an extent by adding a second libc package,
> e.g., libc6.1. But, jejb pointed out that, since most libs depend on
> libc, we'll need to be able to have libs for both interfaces at the
> same time to support a transitional upgrade - and that implies an
> SONAME bump for every C library.
>
> Hopefully there's an easier way, but I don't know of one.

How far away is queeze?

I have to go write some, code, and test some changes, and get back to
the list with some options.

Namely:

Is it possible to change the pthread structures such that writing the
compatibility code is easy?
- Leave padding where the old lock words were and detect statically
initialized locks by looking at these words?
- Does this break Gentoo? I think they just emerge world.
- Does this break Ubuntu hppa? Probably.

Chers,
Carlos.

Re: NTPL transition

[dann frazier]

On Thu, Sep 04, 2008 at 01:29:06PM -0400, Carlos O'Donell wrote:
> On Thu, Sep 4, 2008 at 12:04 PM, dann frazier <dannf@dannf.org> wrote:
> > If we continue to use libc6 as the package name as we're currently
> > doing, at some point libc will get upgraded to the NPTL interface and
> > things will start crashing immediately. I asked if we could just do
> > "whatever x86 did", and kyle said that we have a problem they didn't -
> > our data nptl/lt data structures are incompatible.
> >
> > We can deal with that to an extent by adding a second libc package,
> > e.g., libc6.1. But, jejb pointed out that, since most libs depend on
> > libc, we'll need to be able to have libs for both interfaces at the
> > same time to support a transitional upgrade - and that implies an
> > SONAME bump for every C library.
> >
> > Hopefully there's an easier way, but I don't know of one.
> 
> How far away is queeze?

There's no set timeframe - but I think we can easily assume it will
be at least 1 year after lenny, which is frozen for release now.

> I have to go write some, code, and test some changes, and get back to
> the list with some options.
> 
> Namely:
> 
> Is it possible to change the pthread structures such that writing the
> compatibility code is easy?
> - Leave padding where the old lock words were and detect statically
> initialized locks by looking at these words?
> - Does this break Gentoo? I think they just emerge world.
> - Does this break Ubuntu hppa? Probably.

thanks Carlos

-- 
dann frazier

Re: NTPL transition

[James Bottomley]

On Thu, 2008-09-04 at 10:04 -0600, dann frazier wrote:
> On Thu, Sep 04, 2008 at 11:31:52AM -0400, Carlos O'Donell wrote:
> > On Thu, Sep 4, 2008 at 11:23 AM, dann frazier <dannf@dannf.org> wrote:
> > > I've already done the initial bootstrapping and John Wright and I have
> > > a buildd actively rebuilding bits against sid. We're rsyncing the
> > > results out to here:
> > >  http://parisc-linux.org/~dannf/hppa-nptl-mirror/unstable/
> > >
> > > Suffice to say, the rebuild is going fairly smoothly. But, I wonder
> > > how we're going to transition systems over to an NPTL userspace. Does
> > > anyone have a plan for that?
> > 
> > Isn't this the responsibility of the package manager?
> > 
> > Why wouldn't apt-get dist-upgrade work?
> 
> We had a discussion about this on IRC, a while back, let me see if I
> can recap...
> 
> If we continue to use libc6 as the package name as we're currently
> doing, at some point libc will get upgraded to the NPTL interface and
> things will start crashing immediately. I asked if we could just do
> "whatever x86 did", and kyle said that we have a problem they didn't -
> our data nptl/lt data structures are incompatible.
> 
> We can deal with that to an extent by adding a second libc package,
> e.g., libc6.1. But, jejb pointed out that, since most libs depend on
> libc, we'll need to be able to have libs for both interfaces at the
> same time to support a transitional upgrade - and that implies an
> SONAME bump for every C library.
> 
> Hopefully there's an easier way, but I don't know of one.

Can we go via an intermediate library that would coexist with current
glibc?  Something like libc6-nptl, then we do the transitional update
with the tools and other libraries moving over to libc6-nptl, then the
final piece of the upgrade is libc6 going to nptl based libc6.1 and we
remove the transitional libc6-nptl?  This type of flip will have to be
done via ld.so.conf magic, but it should be doable.

James

Re: NTPL transition

[Domenico Andreoli]

On Thu, Sep 04, 2008 at 12:52:44PM -0500, James Bottomley wrote:
> On Thu, 2008-09-04 at 10:04 -0600, dann frazier wrote:
> > 
> > We had a discussion about this on IRC, a while back, let me see if I
> > can recap...
> > 
> > If we continue to use libc6 as the package name as we're currently
> > doing, at some point libc will get upgraded to the NPTL interface and
> > things will start crashing immediately. I asked if we could just do
> > "whatever x86 did", and kyle said that we have a problem they didn't -
> > our data nptl/lt data structures are incompatible.
> > 
> > We can deal with that to an extent by adding a second libc package,
> > e.g., libc6.1. But, jejb pointed out that, since most libs depend on
> > libc, we'll need to be able to have libs for both interfaces at the
> > same time to support a transitional upgrade - and that implies an
> > SONAME bump for every C library.
> > 
> > Hopefully there's an easier way, but I don't know of one.
> 
> Can we go via an intermediate library that would coexist with current
> glibc?  Something like libc6-nptl, then we do the transitional update
> with the tools and other libraries moving over to libc6-nptl, then the
> final piece of the upgrade is libc6 going to nptl based libc6.1 and we
> remove the transitional libc6-nptl?  This type of flip will have to be
> done via ld.so.conf magic, but it should be doable.

Is it possible to export two different symbols based on the version
used at link time?

This way it would remain libc6, all the pre-existing binaries would use
the older interface wrapped around the new one. Of course newly built
packages would link with the new interface.

ciao,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: NTPL transition

[Carlos O'Donell]

On Thu, Sep 4, 2008 at 1:52 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> Can we go via an intermediate library that would coexist with current
> glibc?  Something like libc6-nptl, then we do the transitional update
> with the tools and other libraries moving over to libc6-nptl, then the
> final piece of the upgrade is libc6 going to nptl based libc6.1 and we
> remove the transitional libc6-nptl?  This type of flip will have to be
> done via ld.so.conf magic, but it should be doable.

No, due to library-to-library dependencies you have the same problem.
You would either have to rebuild *all* the libraries or continue
splitting each library into two packages lib and lib-nptl.

Cheers,
Carlos.

Re: NTPL transition

[James Bottomley]

On Fri, 2008-09-05 at 08:17 -0400, Carlos O'Donell wrote:
> On Thu, Sep 4, 2008 at 1:52 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Can we go via an intermediate library that would coexist with current
> > glibc?  Something like libc6-nptl, then we do the transitional update
> > with the tools and other libraries moving over to libc6-nptl, then the
> > final piece of the upgrade is libc6 going to nptl based libc6.1 and we
> > remove the transitional libc6-nptl?  This type of flip will have to be
> > done via ld.so.conf magic, but it should be doable.
> 
> No, due to library-to-library dependencies you have the same problem.
> You would either have to rebuild *all* the libraries or continue
> splitting each library into two packages lib and lib-nptl.

We are going to have to rebuild all the libraries, that's not an option
because of the ABI change.

The problem is not to avoid this, but to find a way of doing an online
upgrade.  The real problem we have to avoid is breaking system tools
that are required to perform the upgrade in the intermediate steps.  I
don't rule out that will require us to pull this trick with some
libraries in addition to libc, but I don't think it will be all of them.
Just doing libc will probably fix the majority of the issues, though.

James

Re: NTPL transition

[Kyle McMartin]

[Disclaimer: Grain of salt and all that other nonsense, I am pretty
 ignorant about why this is so difficult to handle.]

On Fri, Sep 05, 2008 at 09:07:06AM -0500, James Bottomley wrote:
> > No, due to library-to-library dependencies you have the same problem.
> > You would either have to rebuild *all* the libraries or continue
> > splitting each library into two packages lib and lib-nptl.
> 
> We are going to have to rebuild all the libraries, that's not an option
> because of the ABI change.
> 
> The problem is not to avoid this, but to find a way of doing an online
> upgrade.  The real problem we have to avoid is breaking system tools
> that are required to perform the upgrade in the intermediate steps.  I
> don't rule out that will require us to pull this trick with some
> libraries in addition to libc, but I don't think it will be all of them.
> Just doing libc will probably fix the majority of the issues, though.
> 

I'm probably missing something huge here, but why can't we just put a
sentinel value into the locks, make them equal sized, and use it as a
lock versioning field?

Since our locks are 16-bytes wide traditionally, that leaves us a
bunch of places we could cram it.

There's 3 cases I can think of:
	1 - uninitialized static lock:
		unlocked everywhere else and parisc-nptl (0), locked
		on parisc-lt.

	2 - initialized lock:
		unlocked everywhere else and parisc-*, we end up with
		4 32-bit values each containing a '1' on -lt. presumably
		just 0 on -nptl.

	3 - uninitialized dynamic lock:
		broken everywhere, not really a particular problem.

If we just crammed a "new lock" value (say, 0xdeadbeef or something.)
into the next word of the lock mod 4[1], and assumed any lock without that
sentinel was a linuxthreads lock... 

I mean, aside from wasting 12-bytes of lock that will never be touched
in the -nptl case, it seems like the easiest course...

Since the -lt locks will LDCW the cacheline, it would never be valid to
have an -lt lock with the sentinel set.

Just a thought, but perhaps I am oversimplifying the issue.
	Kyle

1. I mean, if the lock entry is lock[0], we use lock[1], if lock[3], we
	use lock[0].

Re: NTPL transition

[Carlos O'Donell]

On Fri, Sep 5, 2008 at 10:20 AM, Kyle McMartin <kyle@mcmartin.ca> wrote:
> I'm probably missing something huge here, but why can't we just put a
> sentinel value into the locks, make them equal sized, and use it as a
> lock versioning field?

No you aren't missing anything, this is what I meant by "I have to go
write some, code" in my other post.

> Since our locks are 16-bytes wide traditionally, that leaves us a
> bunch of places we could cram it.
>
> There's 3 cases I can think of:
>        1 - uninitialized static lock:
>                unlocked everywhere else and parisc-nptl (0), locked
>                on parisc-lt.

According to POSIX you may only initialize a mutex to an unlocked
state. So we can just treat an uninitialized parisc-lt lock as it it
were an uninitialized parisc-nptl lock. This is the case that "works"
on x86, but is not portable, nor is it correct under POSIX. We want
the same behaviour as x86 so that we can avoid tracking down the bugs
related to uninitialized static locks.

>        2 - initialized lock:
>                unlocked everywhere else and parisc-*, we end up with
>                4 32-bit values each containing a '1' on -lt. presumably
>                just 0 on -nptl.

To be technically correct this is a "static initialized lock" using
something like PTHREAD_MUTEX_INIT. We must version every function that
could have had a statically initialized lock, and at the start of said
function, check the lock words and reset as appropriate. This involves
a) Detect parisc-lt {1,1,1,1} and convert that to {0,0,0,0} b) If the
last word in the lock[4] is zero then do nothing. Note that with
parisc-nptl only the first word is used for locking and it doesn't
have to be more than int aligned.

>        3 - uninitialized dynamic lock:
>                broken everywhere, not really a particular problem.

All the broken packages that memset locks to zero just work on x86 but
not parisc-lt. The parisc porters have to track these down and fix
them. This is one of the reasons we changed the lock behaviour with
the kernel helper. This case should *just work* on parisc-nptl, like
on x86.

> If we just crammed a "new lock" value (say, 0xdeadbeef or something.)
> into the next word of the lock mod 4[1], and assumed any lock without that
> sentinel was a linuxthreads lock...

It's easier than that, you only have to detect the all 1's case. The
all zeroes case IMO can be treated like an uninitialized parisc-nptl
lock.

> I mean, aside from wasting 12-bytes of lock that will never be touched
> in the -nptl case, it seems like the easiest course...
>
> Since the -lt locks will LDCW the cacheline, it would never be valid to
> have an -lt lock with the sentinel set.
>
> Just a thought, but perhaps I am oversimplifying the issue.

It's a good thought.

Cheers,
Carlos.

Re: NTPL transition

[Domenico Andreoli]

On Thu, Sep 04, 2008 at 10:04:07AM -0600, dann frazier wrote:
> On Thu, Sep 04, 2008 at 11:31:52AM -0400, Carlos O'Donell wrote:
> > On Thu, Sep 4, 2008 at 11:23 AM, dann frazier <dannf@dannf.org> wrote:
> > > I've already done the initial bootstrapping and John Wright and I have
> > > a buildd actively rebuilding bits against sid. We're rsyncing the
> > > results out to here:
> > >  http://parisc-linux.org/~dannf/hppa-nptl-mirror/unstable/
> > >
> > > Suffice to say, the rebuild is going fairly smoothly. But, I wonder
> > > how we're going to transition systems over to an NPTL userspace. Does
> > > anyone have a plan for that?
> > 
> > Isn't this the responsibility of the package manager?
> > 
> > Why wouldn't apt-get dist-upgrade work?
> 
> We had a discussion about this on IRC, a while back, let me see if I
> can recap...
> 
> If we continue to use libc6 as the package name as we're currently
> doing, at some point libc will get upgraded to the NPTL interface and
> things will start crashing immediately. I asked if we could just do
> "whatever x86 did", and kyle said that we have a problem they didn't -
> our data nptl/lt data structures are incompatible.
> 
> We can deal with that to an extent by adding a second libc package,
> e.g., libc6.1. But, jejb pointed out that, since most libs depend on
> libc, we'll need to be able to have libs for both interfaces at the
> same time to support a transitional upgrade - and that implies an
> SONAME bump for every C library.

I am not understanding why "we'll need to be able to have libs for both
interfaces at the same time to support a transitional upgrade".

Suppose the new libc6 (LT) is a compatibility wrapper around new libc6.1
(NPTL). The remainder is really an apt's job.

cheers,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: NTPL transition

[Petr Salinger]

> To be technically correct this is a "static initialized lock" using
> something like PTHREAD_MUTEX_INIT. We must version every function that
> could have had a statically initialized lock, and at the start of said
> function, check the lock words and reset as appropriate. This involves
> a) Detect parisc-lt {1,1,1,1} and convert that to {0,0,0,0} b) If the
> last word in the lock[4] is zero then do nothing. Note that with
> parisc-nptl only the first word is used for locking and it doesn't
> have to be more than int aligned.

IMHO, there is no need for versioning. Moreover it wouldn't be sufficient.

Imagine function in a shared library foo which takes as argument 
pthread_mutex_t and does usual:

 	pthread_mutex_lock()
 	do some work
 	pthread_mutex_unlock()

And a program bar, which uses foo. Inside bar is a static initialized 
lock. The foo might be (re)compiled against NPTL, while bar would be 
still compiled against LT. Therefore check_and_reset() should be called as 
long as any installed (debian) package have not been recompiled against 
NPTL. The overhead of check_and_reset() looks very small, it should be no 
problem at all. The harder part is to determine each place, where
check_and_reset() should be called. It have to be in all places,
where static initialized lock might be passed for the 1st time,
i.e. it should be in  pthread_mutex_lock(), but not in
pthread_mutex_unlock().

Petr

Re: NTPL transition

[Carlos O'Donell]

On Sat, Sep 6, 2008 at 4:24 AM, Petr Salinger <Petr.Salinger@seznam.cz> wrote:
> IMHO, there is no need for versioning. Moreover it wouldn't be sufficient.

You must versioning the affected interfaces, otherwise you will never
be able to remove the compatibility code.

> Imagine function in a shared library foo which takes as argument
> pthread_mutex_t and does usual:
>
>        pthread_mutex_lock()
>        do some work
>        pthread_mutex_unlock()
>
> And a program bar, which uses foo. Inside bar is a static initialized lock.
> The foo might be (re)compiled against NPTL, while bar would be still
> compiled against LT. Therefore check_and_reset() should be called as long as
> any installed (debian) package have not been recompiled against NPTL. The
> overhead of check_and_reset() looks very small, it should be no problem at
> all. The harder part is to determine each place, where
> check_and_reset() should be called. It have to be in all places,
> where static initialized lock might be passed for the 1st time,
> i.e. it should be in  pthread_mutex_lock(), but not in
> pthread_mutex_unlock().

Yes, certainly, this is a valid case.

Any function that manipulates a changed structure needs to be versioned.

Eventually, one day, debian hppa will configure glibc with
--enable-oldest-abi at a high enough value that the compat code will
be dropped (because we have proved no package needs it and we have an
upgrade path).

Do you have any other concerns?

Cheers,
Carlos.

Re: NTPL transition

[Petr Salinger]

>> IMHO, there is no need for versioning. Moreover it wouldn't be sufficient.
>
> You must versioning the affected interfaces, otherwise you will never
> be able to remove the compatibility code.
>
>> Imagine function in a shared library foo which takes as argument
>> pthread_mutex_t and does usual:
>>
>>        pthread_mutex_lock()
>>        do some work
>>        pthread_mutex_unlock()
>>
>> And a program bar, which uses foo. Inside bar is a static initialized lock.
>> The foo might be (re)compiled against NPTL, while bar would be still
>> compiled against LT. Therefore check_and_reset() should be called as long as
>> any installed (debian) package have not been recompiled against NPTL. The
>> overhead of check_and_reset() looks very small, it should be no problem at
>> all. The harder part is to determine each place, where
>> check_and_reset() should be called. It have to be in all places,
>> where static initialized lock might be passed for the 1st time,
>> i.e. it should be in  pthread_mutex_lock(), but not in
>> pthread_mutex_unlock().
>
> Yes, certainly, this is a valid case.
>
> Any function that manipulates a changed structure needs to be versioned.
>
> Eventually, one day, debian hppa will configure glibc with
> --enable-oldest-abi at a high enough value that the compat code will
> be dropped (because we have proved no package needs it and we have an
> upgrade path).
>
> Do you have any other concerns?

The versioning does not help here, i.e. in the above case
bar will not reference any old (linuxthread variant) function,
therefore it would look like there is no need for compat code, even though 
it will be still needed.

For dropping compat code, you have to be sure any package is not compiled 
against old glibc - it can be determined in debian from Depends: line
in binary package control file. The strategy for upgrade might be easy;
For lenny+1 include compat code, but make sure all of lenny+1 released
packages are build against NPTL variant. The compact code can be dropped
just after lenny+1 release.

It looks like one compare will say it is not LT initialized lock,
this path might be really fast.
IMHO, even including such compat code forever will be easier compared to 
transition all libraries ...

The check_and_reset() should be reasonably "atomic" - two threads might 
call pthread_mutex_lock() on static LT initialized lock in the same time.

What are the difference between LT and NPTL definition of pthread_mutex_t.
Only 3 unused ints in pthread_mutex_t ?

Petr

Re: NTPL transition

[Carlos O'Donell]

On Sat, Sep 6, 2008 at 4:16 PM, Petr Salinger <Petr.Salinger@seznam.cz> wrote:
>> Do you have any other concerns?
>
> The versioning does not help here, i.e. in the above case
> bar will not reference any old (linuxthread variant) function,
> therefore it would look like there is no need for compat code, even though
> it will be still needed.

Yes, I agree with you, but you still need symbol versioining.

The point of versioning the symbols is so that in the future when you
run an old program you will get the error "Undefined reference to
symbol foo" instead of a random crash. So the procedure is this:

1. Create an old compat function at version 2.0, which is only
compiled if oldest ABI is 2.0.
2. Create a new function at version 2.8, which *also* contains compat
code wrapped in "#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_8)".

With oldest-abi at 2.0, all functions will have the compat checks
enabled, allowing mixing of old applications and new libraries.
Eventually when you build with oldest ABI 2.8, the 2.0 version
functions are gone, the compat code in 2.8 version functions is
dropped, and everything is working optimally. When you run an old
application it complains "Undefined reference to symbol foo", and
rightly so because we only support the new ABI.

Do you see any problem with that?

> For dropping compat code, you have to be sure any package is not compiled
> against old glibc - it can be determined in debian from Depends: line
> in binary package control file. The strategy for upgrade might be easy;
> For lenny+1 include compat code, but make sure all of lenny+1 released
> packages are build against NPTL variant. The compact code can be dropped
> just after lenny+1 release.

Yes, that's probably a good procedure.

However, you can't determine it from the depends line because libc is
an implicit depend?

I believe you have to analyze the binaries in the archive.

> It looks like one compare will say it is not LT initialized lock,
> this path might be really fast.
> IMHO, even including such compat code forever will be easier compared to
> transition all libraries ...

Yes, I agree.

> The check_and_reset() should be reasonably "atomic" - two threads might call
> pthread_mutex_lock() on static LT initialized lock in the same time.

It will be 100% atomic, we will use hppa's load-and-clear-word
instruction to analyze the contents of the old lock structure.

> What are the difference between LT and NPTL definition of pthread_mutex_t.
> Only 3 unused ints in pthread_mutex_t ?

A function that takes as an argument a structure that has no padding
left for a new 4-byte int aligned lock and contains a statically
initialized __atomic_lock_t that we must reuse for our lock.

We must review these structures for possible padding to use as a lock word:
pthread_cond_t
pthread_mutex_t
pthread_rwlock_t
pthread_barrier_t
pthread_spinlock_t

>From this list, only those that have static initializers may cause an
ABI issue, namely:
PTHREAD_COND_INITIALIZER
PTHREAD_MUTEX_INITIALIZER
PTHREAD_RWLOCK_INITIALIZER (Deleted in issue 6)

Lastly the complete list of functions that may need compat:
pthread_cond_timedwait
pthread_cond_wait
pthread_mutex_destroy
pthread_mutex_getprioceiling
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_setprioceiling
pthread_mutex_timedlock
pthread_mutex_trylock
pthread_mutex_unlock
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_rwlock_destroy
pthread_rwlock_init
pthread_rwlock_rdlock
pthread_rwlock_timedrdlock
pthread_rwlock_timedwrlock
pthread_rwlock_tryrdlock
pthread_rwlock_trywrlock
pthread_rwlock_unlock
pthread_rwlock_wrlock

Please feel free to review my list.

I based this list on the data here:
http://www.opengroup.org/onlinepubs/009695399/

Cheers,
Carlos.

Re: NTPL transition

[Carlos O'Donell]

On Sat, Sep 6, 2008 at 4:24 AM, Petr Salinger <Petr.Salinger@seznam.cz> wrote:
> Imagine function in a shared library foo which takes as argument
> pthread_mutex_t and does usual:
>
>        pthread_mutex_lock()
>        do some work
>        pthread_mutex_unlock()
>
> And a program bar, which uses foo. Inside bar is a static initialized lock.
> The foo might be (re)compiled against NPTL, while bar would be still
> compiled against LT. Therefore check_and_reset() should be called as long as
> any installed (debian) package have not been recompiled against NPTL. The
> overhead of check_and_reset() looks very small, it should be no problem at
> all. The harder part is to determine each place, where
> check_and_reset() should be called. It have to be in all places,
> where static initialized lock might be passed for the 1st time,
> i.e. it should be in  pthread_mutex_lock(), but not in
> pthread_mutex_unlock().

I reviewed the compatibility provided by glibc for the pthread_cond_t
change in 2.3.2, and I see no such guarantee that an address of a
pthread_cont_t in an old binary can be safely passed to a library
rebuilt against the new libc . When upstream changed pthread_cond_t,
making it larger, they versioned the interface, and the old function
mallocs a pointer to the new structure and call the new function with
the newly malloc'd structure.

I think 99% of all situations are covered by providing an old
function. Guarding the new function against a mixed ABI use seems like
a performance penalty with an unknown benefit. Clearly if upstream
glibc didn't think it was usefull, should we also ignore this
scenario?

I have compat patches in testing on my SMP parisc64 box. I should have
some results by next week.

Cheers,
Carlos.