DragonFly kernel List (threaded) for 2007-06
From: Matthew Dillon <firstname.lastname@example.org>
Subject: Re: Decision time.... should NATA become the default for this release?
Date: Sun, 3 Jun 2007 21:49:54 -0700 (PDT)
References: <200706010035.l510ZnpS009485@apollo.backplane.com> <email@example.com> <200706011734.l51HYO5a018589@apollo.backplane.com> <firstname.lastname@example.org> <200706021731.l52HVvQ1036684@apollo.backplane.com> <email@example.com> <firstname.lastname@example.org> <200706032002.l53K2Y57051206@apollo.backplane.com> <4663214A.email@example.com> <200706032036.l53KaIsJ051688@apollo.backplane.com> <46636C1D.firstname.lastname@example.org.
X-Trace: 1180933011 crater_reader.dragonflybsd.org 797 220.127.116.11
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:11125
:Excellent work Matt,
:Now that NATA will almost certainly be the default, what about other
:DragonFly technology that has been cooking in the pot, the new threading
:library, is it ready for prime time/to be made default in the system?
:Perhaps not for the release but in HEAD.
A lot of great work on the kernel API and backend LWP support has gone
in recently. If not this release, then definitely the end-of-year
release. I think it depends on what the developers who are currently
testing libthread_xu/LWP think.
In HEAD the threading library can be changed on the fly, without
having to recompile anything. /usr/lib/libpthread.a and
/usr/lib/libpthread.so.0 are just softlinks that point either to
libc_r.a/libc_r.so, or to libthread_xu.a/libthread_xu.so. So its
very easy for anyone to test it.
I've made a huge amount of progress on the precursor work required
to develop a new filesystem, but the user<->kernel syslink
infrastructure took two months longer then I thought it would so
I'm behind on the rest of the work. Here's what we have now:
* 64 bit I/O paths, 48 bit backend block addressing for devices that
* NATA will be the default
* user<->kernel syslink
* major LWP infrastructure is now in place
* GCC-3.x will still be the default, but GCC-4.x will be built
automatically and can be selected via CCVER (as per usual).
And here is what I expect to finish for the release:
* disklabel infrastructure abstraction
* GPT disklabel support
* userfs VFS backend in the kernel
And here is what I do NOT expect to have finished for this release:
* No new filesystem yet, but definitely by end-of-year.
* No significant progress on clustering protocols yet, except
for the syslink messaging core and some SYSID indexing
(the SYSREF work I did earlier).
* Interrupt routing still needs a lot of love.
With this release the decks should be clear to get the new
filesystem done for the end-of-year release (2.2). It and perhaps
some more of the clustering code will literally be the only things
I will be working on for the end-of-year 2.2 release cycle. The
new filesystem is A#1 on my priority list after this release.