No subject

[Unknown]

au>
From: Matthew Dillon <dillon at 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 at crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel at crater.dragonflybsd.org>
References: <200706010035.l510ZnpS009485 at apollo.backplane.com>	<20070601070043.9d029075.steve at sohara.org>	<200706011734.l51HYO5a018589 at apollo.backplane.com>	<20070602130631.7bd7f2a8.steve at sohara.org>	<200706021731.l52HVvQ1036684 at apollo.backplane.com>	<20070603093100.01fabca7.steve at sohara.org> <20070603155242.1e73a84e.steve at sohara.org> <200706032002.l53K2Y57051206 at apollo.backplane.com> <4663214A.40000 at fs.ei.tum.de> <200706032036.l53KaIsJ051688 at apollo.backplane.com> <46636C1D.1060203 at exemail.com.
au>
Sender: kernel-errors at crater.dragonflybsd.org
Errors-To: kernel-errors at 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 at backplane.com>