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 [EMAIL PROTECTED]:/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: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
msg02998/pgp00000.pgp
Description: PGP signature
