bug-hurd
[Top][All Lists]
Advanced

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

Re: [Hurd-devel-readers] Re: Checks-syms results


From: Jeroen Dekkers
Subject: Re: [Hurd-devel-readers] Re: Checks-syms results
Date: Sun, 24 Feb 2002 03:27:54 +0100
User-agent: Mutt/1.3.27i

On Sat, Feb 23, 2002 at 08:24:36PM -0500, Roland McGrath wrote:
> > Question - Do you have a plan for what makes it a "0.3" ABI vs. a
> > "1.0" ABI?  If this should be a fairly stable and long term change, it
> > might be nice to have at least something of ours at a 1.0 stage.
> 
> :-) Well, it's still not perfect yet.  And hey, GNU Mach is at 1.2!  When
> we finally mainline oskit-mach I will be more than happy to call it 2.0 if
> that makes you feel extra warm and fuzzy.  

I already asked Marcus and Jeff on IRC whether OSKit-Mach is going to
be gnumach 2.0. I think having OSKit-Mach the default kernel of the CD
images containing the libc0.3 would be nice and will have yet another
big change on those CDs. The only problem is that I'm not sure how
stable OSKit-Mach is when running for a long time. Because the console
wasn't usable I never tried for longer than a few minutes.

> Despite my best intentions, I still think all our current ABIs are just a
> draft and we might be doing this all over again before we're happy.  It's
> possible that the final integrated pthreads and signal rewrite will happen
> without losing current ABI compatibility, but being realistic I have to be
> a bit skeptical.

I don't know what exactly needs to be done for the signal code, but I
can give you a list of things needed for pthreads:
* I've to study TLS and the implementation in glibc, especially the
linuxthreads code. TLS needs to be supported in pthreads and all thing
regarding thread local storage in the Hurd part of glibc needs to be
changed. The TLS code is really nice and causes less work for me,
because the old cthreads stuff didn't work anyway for pthreads stacks.
* Cancellation support and the pthread's signalling semantics. I'm not
sure yet what's all needed for this, but I'm already a bit familiar
with hurdsig.c.
* The current way of blocking needs to be checked. There could be some
races in it. There might also be other problems.
* It needs to be intergrated into glibc. The build process is now just
only making object files to check for stupid errors.
* Check if we are POSIX compliant. Especially about checking if the
arguments are right. (i.e. if a thread still exists etc.) This can
heavily change the ABI, as some things like condition variables
could change to pointers to a struct instead of the struct itself.
* Fix everything marked with XXX/FIXME in the code and everything in
the TODO list.
* The code is never run, so I expect a lot of bugs which need to be
fixed.
* Ulrich gave some comments to Mark a few years ago, I don't know how
important and up-to-date those are.
* I (and maybe others who have worked on it) need to assign copyright
to the FSF.
* All other things I forget at the moment. It looks like I have
everything here.

You can get the current code with:
cvs -z3 -ddevelopername@subversions.gnu.org:/cvsroot/pthreads/ co pthreads

You're already added to the savannah project in the case you want to
change something. :)

I've some uncommitted changed in my repository regarding
rwlocks. Those are half implemented, I can commit them if you want. I
rather first fix them however. I planned pthreads hacking this week,
I've got holidays. :)

> I still want to have another ABI shift with more
> libraries or more nuanced use of symbol versions, or something, so as to
> distinguish programs that use the POSIX/generic-GNU parts of the ABI vs
> Hurd-specific functions and such. 

Yeah, splitting glibc up in multiple libraries would be cool. It's
already done at source level AFAICS.

> It could be that that shift can also be
> the one to harmonize with the (future or current, as it goes) GNU/Linux
> ABIs.  That could be the next shift or there could be some in
> between.

Having the same ABI for GNU/Linux and GNU/Hurd would be nice,
especially for the Debian project. A lot of the linux-* binaries could
be the same as the hurd-* binaries. This is certainly appreciated with
a hurd-powerpc port underway. ;-)

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: pgpX2vYTzWBGt.pgp
Description: PGP signature


reply via email to

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