[Top][All Lists]

[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:02:46 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)


On Sat, 04 Aug 2012 13:02:10 +0200, "Neal H. Walfield" <neal@walfield.org> 
> At Sat, 4 Aug 2012 12:34:28 +0200,
> Thomas Schwinge wrote:
> > There has been a libpthread port for Hurd on L4 use, which is dead, and
> > has been superseded by a Viengoos port, which has its own branches:
> For what it is worth, the L4 port works directly on L4: no further OS
> personality support is required.  On the other hand, no one actually
> uses it so I guess it is okay to remove it.

Yes -- and the nice thing about each Git repository clone carrying the
whole history is that it can rather easily be resurrected if needed.

> > master-viengoos and its successor, master-viengoos-on-bare-metal.
> master-viengoos is an implementation of Viengoos that runs on L4.
> viengoos-on-bare-metal runs directly on x86-64 (and it a bit more
> advanced) and provides everything that master-viengoos does and more.
> I unfortunately never got around to issuing the right git commands to
> make turn it into the master branch.

Note that I'm talking about branches of the hurd/libpthread.git
repository, which contains only the libpthread branches (as used by Hurd
on Mach: master, old L4: master, Viengoos: master-viengoos and
viengoos-on-bare-metal), and not the hurd/viengoos.git repository which
contains all the other Viengoos code.

> > * 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).  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.)

> > In August 2008, Neal has been porting over some generic changes from the
> > Viengoos branch to master, and I'm now identifying if there are
> > additional changes to be ported.
> That's a good idea.  Unfortunately, I don't remember how far I got.

It's not very much that is missing; I think I already extracted most of
it, and will post that soon.

> Note: libpthread is not without its problems, e.g., lack of testing in
> the wild.  I still think the better way forward is to use Glibc's
> pthread, if possible.

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.


Attachment: pgptXTMvOY367.pgp
Description: PGP signature

reply via email to

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