Re: NTPL transition

[Kyle McMartin <kyle@mcmartin.ca>]

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