bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libpthread cleanup: L4 port, PowerPC port


From: Thomas Schwinge
Subject: Re: libpthread cleanup: L4 port, PowerPC port
Date: Sat, 4 Aug 2012 15:56:01 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)

Hi!

On Sat, 04 Aug 2012 15:16:22 +0200, "Neal H. Walfield" <neal@walfield.org> 
wrote:
> At Sat, 4 Aug 2012 15:02:46 +0200,
> Thomas Schwinge wrote:
> > > > * signal/README: Likewise.
> > > > * signal/TODO: Likewise.
> > > > * signal/kill.c: Likewise.
> > > > * signal/pt-kill-siginfo-np.c: Likewise.
> > > > * signal/sig-internal.c: Likewise.
> > > > * signal/sig-internal.h: Likewise.
> > > > * signal/sigaction.c: Likewise.
> > > > * signal/sigaltstack.c: Likewise.
> > > > * signal/signal-dispatch.c: Likewise.
> > > > * signal/signal.h: Likewise.
> > > > * signal/sigpending.c: Likewise.
> > > > * signal/sigsuspend.c: Likewise.
> > > > * signal/sigtimedwait.c: Likewise.
> > > > * signal/sigwaiter.c: Likewise.
> > > > * signal/sigwaitinfo.c: Likewise.
> > > > * sysdeps/generic/killpg.c: Likewise.
> > > > * sysdeps/generic/raise.c: Likewise.
> > > > * sysdeps/generic/sigaddset.c: Likewise.
> > > > * sysdeps/generic/sigdelset.c: Likewise.
> > > > * sysdeps/generic/sigemptyset.c: Likewise.
> > > > * sysdeps/generic/sigfillset.c: Likewise.
> > > > * sysdeps/generic/siginterrupt.c: Likewise.
> > > > * sysdeps/generic/sigismember.c: Likewise.
> > > > * sysdeps/generic/signal.c: Likewise.
> > > > * sysdeps/generic/sigwait.c: Likewise.
> > > 
> > > I think these are also used by the Viengoos port.  Are you suggesting
> > > to remove both the L4 and the Viengoos ports or just the L4 port?
> > 
> > I only intend to clean up libpthread's master branch (that is, remove its
> > old L4 port).
> 
> Ok.  I still think that the above files are generic and not L4
> specific.

Does that mean you'd like to keep them available in the master branch,
though unused there?  (In principle I'm fine either way, but have a
tendency towards only having code live in the repositories that is
actually being used.)


> > On libpthread's master-viengoos and viengoos-on-bare-metal
> > branches, the Viengoos-specific code stays as-is, and can continue to
> > evolve there, with the long-term goal of eventually merging it back into
> > libpthread's master branch as a new Viengoos port of libpthread.  (I
> > guess that you only started using Viengoos-specific branches for
> > libpthread for the reason of being able to easily do changes in the
> > generic libpthread code without disturbing/having to adapt the Hurd on
> > Mach port.)
> 
> My recollection is that Hurd was in CVS at the time.  You(?) created
>  libpthread.git later.

I did do the conversion/extraction of libpthread, yes.  There were two
copies: one in the hurd repository, one in the hurd-l4 one, which I
combined into a single Git one, at the appropriate branch point.  And it
indeed seems you/we created the separate Viengoos branches later on.


> > Yes, but I think given the testing it is seeing via Debian GNU/Hurd, your
> > libpthread not so bad actually.  In the long term, and given someone
> > willing to do it, a NPTL port would of course be possible/preferable/...,
> > too.  But I don't think that's a priority currently.
> 
> If you have time, I'd recommend that you also take a look at the
> asserts and disable the more expensive ones.  For instance in
> sysdeps/mach/hurd/pt-sysdep.h, _pthread_self checks that the
> thread->kernel_thread matches _mach_thread_self().  This requires two
> system calls!  _pthread_self should be fast...

Thanks, noted.


Grüße,
 Thomas

Attachment: pgpeBjqHVRwb4.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]