DragonFly kernel List (threaded) for 2007-06
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
[no subject]
au>
From: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: Decision time.... should NATA become the default for this release?
Date: Sun, 3 Jun 2007 21:49:54 -0700 (PDT)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
References: <200706010035.l510ZnpS009485@apollo.backplane.com> <20070601070043.9d029075.steve@sohara.org> <200706011734.l51HYO5a018589@apollo.backplane.com> <20070602130631.7bd7f2a8.steve@sohara.org> <200706021731.l52HVvQ1036684@apollo.backplane.com> <20070603093100.01fabca7.steve@sohara.org> <20070603155242.1e73a84e.steve@sohara.org> <200706032002.l53K2Y57051206@apollo.backplane.com> <4663214A.40000@fs.ei.tum.de> <200706032036.l53KaIsJ051688@apollo.backplane.com> <46636C1D.1060203@exemail.com.
au>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 57
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1180933011 crater_reader.dragonflybsd.org 797 216.240.41.25
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.
:
:Petr
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
support it
* 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.
-Matt
Matthew Dillon
<dillon@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]