NTPL transition

[Domenico Andreoli-5]

Hi all,

  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 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 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? :)

cheers,
Domenico

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

[Carlos O'Donell-2]

On Thu, Sep 4, 2008 at 7:45 AM, Domenico Andreoli <cavok@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Thu, Sep 4, 2008 at 11:23 AM, dann frazier <dannf@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Thu, Sep 4, 2008 at 12:04 PM, dann frazier <dannf@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[James Bottomley-2]

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



--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Domenico Andreoli-5]

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Domenico Andreoli-5]

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Thu, Sep 4, 2008 at 1:52 PM, James Bottomley
<James.Bottomley@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[James Bottomley-2]

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



--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kyle McMartin-4]

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Fri, Sep 5, 2008 at 10:20 AM, Kyle McMartin <kyle@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

> 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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Sat, Sep 6, 2008 at 4:24 AM, Petr Salinger <Petr.Salinger@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

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


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact