NTPL transition
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Domenico Andreoli
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 15 lines · Carlos O'Donell
Quoted 4 lines · Domenico Andreoli
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.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 3 lines
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?
Signature · 1 line
dann frazier
Quoted 8 lines · dann frazier
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.
Quoted 6 lines · Carlos O'Donell
Quoted 5 lines · dann frazier
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/
Quoted 7 lines
Quoted 3 lines
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.
Signature · 1 line
dann frazier
Quoted 6 lines · dann frazier
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.
Quoted 7 lines
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.
Quoted 13 lines · Carlos O'Donell
Quoted 12 lines · dann frazier
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.
Quoted 3 lines
Quoted 1 line
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.
Quoted 11 lines
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
Signature · 1 line
dann frazier
Quoted 24 lines · dann frazier
Quoted 6 lines · Carlos O'Donell
Quoted 5 lines · dann frazier
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/Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
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
Quoted 17 lines · James Bottomley
Quoted 16 lines · dann frazier
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.
Quoted 8 lines
Quoted 1 line
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
Quoted 6 lines · James Bottomley
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.
Quoted 9 lines · Carlos O'Donell
Quoted 6 lines · James Bottomley
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.
Quoted 3 lines
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
[Disclaimer: Grain of salt and all that other nonsense, I am pretty
ignorant about why this is so difficult to handle.]
Quoted 7 lines · James Bottomley
Quoted 3 lines
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.
Quoted 7 lines
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].
Quoted 3 lines · Kyle McMartin
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.
Quoted 7 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
If we just crammed a "new lock" value (say,
0xdeadbeefor 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.
Quoted 7 lines
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.
Quoted 24 lines · dann frazier
Quoted 6 lines · Carlos O'Donell
Quoted 5 lines · dann frazier
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/Quoted 7 lines
Quoted 3 lines
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.
Quoted 5 lines
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