Re: HPPA linux compat wrappers
On Mon, Jun 22, 2009 at 6:51 AM, Petr Salinger<Petr.Salinger@seznam.cz> wrote:
>> However, the usability testing in a chroot + vnc is showing that some
>> applications are segfaulting. I've been looking into this today.
>
> I still think there should be support for mixed ABI calls.
> See also thread http://lists.debian.org/debian-hppa/2008/09/msg00018.html
It sounds like a good feature, but my time is restricted so I
implemented the simplest interface possible that I could prove worked.
If you have ample free time I suggest you post a version of the patch
with your enhancements. I'd be more than willing to test your patches.
> The question is why have been sizeof(pthread_cond_t)
> expanded from 48 bytes under linuxthreads into
> 64 bytes under NPTL. I do not see a reson for it.
> IMHO, it might significantly break compatibility.
This is technically a mistake, the new NPTL structure should be 48
bytes as well. I'll fix that in my sources.
However, it doesn't break compatibility in the current patches, only
in your scheme of mixed ABI support.
> The current NPTL implementation zeroes all the fields at the begining,
> doesn't it ?
Which implementation? The compat code? No, it uses the ldcw spinlock
to protect structure accesses.
> So at the begin of each affected function will be (asm coded ?)
>
> if (v->__lt_compat)
> {
> lock_global_pt_lock();
> if (v->__lt_compat)
> {
> zero_all_but_lt_compat_field();
> barrier();
> v->__lt_compat = 0;
> };
> unlock_global_pt_lock();
> };
>
> For the new NPTL layout the zeroing code will not be taken,
> therefore almost no overhead.
> There might be a congestion on global_pt_lock, but I do not believe,
> there are many static initilized mutexes in any real program.
> There will be no need for allocation any new structures.
There are tons of statically initialized mutexs, gnome and gdk are
full of them as an example.
> The drawback is hppa specific pthread.h or need to convince Uli
> to add unused zeroed field into affected structures globally.
That is no longer a drawback, most machines these days need to copy
core header files and modify.
Cheers,
Carlos.
Reply to: