Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-01!sn-xit-09!supernews.com!newsfeed.news2me.com!newshosting.com!news-xfer1.atl.newshosting.com!167.206.3.103.MISMATCH!news3.optonline.net!ctu-peer!news.nctu.edu.tw!netnews.chu.edu.tw!FreeBSD.csie.NCTU.edu.tw!not-for-mail
From: dil...@apollo.backplane.com (Matthew Dillon)
Newsgroups: mailing.freebsd.stable
Subject: Announcing DragonFly BSD!
Date: Wed, 16 Jul 2003 19:43:16 +0000 (UTC)
Organization: NCTU CSIE FreeBSD Server
Lines: 63
Sender: nob...@FreeBSD.csie.NCTU.edu.tw
Message-ID: <bf49sk$2bsk$1@FreeBSD.csie.NCTU.edu.tw>
NNTP-Posting-Host: freebsd.csie.nctu.edu.tw
X-Trace: FreeBSD.csie.NCTU.edu.tw 1058384596 77717 140.113.17.209 (16 Jul 2003 19:43:16 GMT)
X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw
NNTP-Posting-Date: Wed, 16 Jul 2003 19:43:16 +0000 (UTC)
Announcing DragonFly BSD!
http://www.dragonflybsd.org/
Hello everyone! For the last few months I have been investigating
and then working on a new approach to the BSD kernel. This has snowballed
into a far more ambitious project which is now ready for wider
participation.
It is the intent of this project to take over development of the 4.x tree,
to move kernel development along an entirely new path towards SMP, and
to completely rewrite the packaging and distribution system. We
eventually intend to backport many FreeBSD-5 features into the new tree,
but that is not where the initial focus will be.
The preliminary 'proving' work I have done is now available on the new
DragonFly site. You can access it through cvsup or browse it through
ftp. This proving work involved implementing much of the earlier UP->SMP
converstion work that was done when 5.x first branched, but under an
entirely new mutex-free light weight kernel threading infrastructure.
It includes the LWKT system, interrupt threads, and pure threads for
system processes amoung other things.
For obvious reasons the codebase will only run on i386 for now, and ports
to other platforms will not happen until the MD infrastructure is cleaned
up and finalized. I considered starting with a 5.x base but it is simply
too heavily mutexed, it was actually faster to start with 4.x and move
forward rather then to start with 5.x and move backwards.
I have both UP and SMP builds working in the current codebase. I believe
it proves out the core concepts quite nicely and there is much
more work coming down the pipeline.
The site is:
http://www.dragonflybsd.org/
Hopefully my T1 can handle the cvsup load. Eventually I'll colocate
some boxes to deal with that issue.
For the next few months the project is going to concentrate on low
level kernel development. There are still a number of big ticket items
that have to be accomplished, primarily in converting the I/O path to
using VM Object/range lists, before work can branch out into other areas.
I expect the project to start fairly slowly but then for momentum to
build.
Anyone interested in working on or discussing the project is welcome! I
have created a mailing list server and newsgroup forums and I am working
on web-accessibility to same for passive listeners. I will be posting
periodic updates to freebsd-hackers as well.
Again, the site is below. It contains a great deal of documentation
and other information. I even have a mascot! And, hopefully, it will
all work from outside my LAN :-)
http://www.dragonflybsd.org/
-Matt
_______________________________________________
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd
Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!64.152.100.70.MISMATCH!sjc70.webusenet.com!news.webusenet.com!cyclone.bc.net!newsfeed.media.kyoto-u.ac.jp!diablo.efnet.com!efnet.com!ctu-peer!news.nctu.edu.tw!netnews.chu.edu.tw!FreeBSD.csie.NCTU.edu.tw!not-for-mail
From: ku...@tenebras.com (Michael Sierchio)
Newsgroups: mailing.freebsd.stable
Subject: Re: Announcing DragonFly BSD!
Date: Wed, 16 Jul 2003 20:12:36 +0000 (UTC)
Organization: NCTU CSIE FreeBSD Server
Lines: 28
Sender: nob...@FreeBSD.csie.NCTU.edu.tw
Message-ID: <bf4bjk$2d2r$1@FreeBSD.csie.NCTU.edu.tw>
NNTP-Posting-Host: freebsd.csie.nctu.edu.tw
X-Trace: FreeBSD.csie.NCTU.edu.tw 1058386356 78940 140.113.17.209 (16 Jul 2003 20:12:36 GMT)
X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw
NNTP-Posting-Date: Wed, 16 Jul 2003 20:12:36 +0000 (UTC)
Matthew Dillon wrote:
> Anyone interested in working on or discussing the project is welcome! I
> have created a mailing list server and newsgroup forums and I am working
> on web-accessibility to same for passive listeners. I will be posting
> periodic updates to freebsd-hackers as well.
I'm especially encouraged by the committment to fix the VFS subsystem
so that stackable filesystems will really work, by the caching/locking
discussion, and the acknowledgement that system configuration and packages
need a publish-subscribe (not Matt's words) mechanism.
Manuel Kasper's m0n0wall configuration system, XML-based, is
really cool. You could easily extend it to signed XML for
trusted packages/components.
Crypto and ACL filesystems could finally be done in a modular,
stackable way. Esp. if the messaging subsystem works as
advertised.
This announcement has made an otherwise dreary and mind-numbing day at
work a little better, thanks.
_______________________________________________
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-01!sn-xit-09!supernews.com!newsfeed-east.nntpserver.com!nntpserver.com!news3.optonline.net!ctu-peer!news.nctu.edu.tw!netnews.chu.edu.tw!FreeBSD.csie.NCTU.edu.tw!not-for-mail
From: dil...@apollo.backplane.com (Matthew Dillon)
Newsgroups: mailing.freebsd.stable
Subject: Re: Announcing DragonFly BSD!
Date: Wed, 16 Jul 2003 20:29:19 +0000 (UTC)
Organization: NCTU CSIE FreeBSD Server
Lines: 56
Sender: nob...@FreeBSD.csie.NCTU.edu.tw
Message-ID: <bf4civ$2dqu$1@FreeBSD.csie.NCTU.edu.tw>
NNTP-Posting-Host: freebsd.csie.nctu.edu.tw
X-Trace: FreeBSD.csie.NCTU.edu.tw 1058387359 79711 140.113.17.209 (16 Jul 2003 20:29:19 GMT)
X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw
NNTP-Posting-Date: Wed, 16 Jul 2003 20:29:19 +0000 (UTC)
:I'm especially encouraged by the committment to fix the VFS subsystem
:so that stackable filesystems will really work, by the caching/locking
:discussion, and the acknowledgement that system configuration and packages
:need a publish-subscribe (not Matt's words) mechanism.
:
:Manuel Kasper's m0n0wall configuration system, XML-based, is
:really cool. You could easily extend it to signed XML for
:trusted packages/components.
:
:Crypto and ACL filesystems could finally be done in a modular,
:stackable way. Esp. if the messaging subsystem works as
:advertised.
:
:This announcement has made an otherwise dreary and mind-numbing day at
:work a little better, thanks.
That is the intent. Also the ability to develop and debug VFS layers
as userland processes, or even run non-critical filesystems like msdosfs
and cd9660 in userland outright.
Fixing VFS is probably the single most difficult problem that we will
face. Fixing DEV (which I am going to do as soon as I change the
I/O system over to using VM object ranges) is a lot easier because DEV
entry points are already inherently asynch, or easily asynchronized.
E.g. the IDE driver takes a request and 'queues' it for action. The
UFS filesystem, on the otherhand, executes the request synchronously
in the context of the caller and may sleep/wakeup many times. There is
a big difference.
Fixing VFS will require breaking it first... that is, it will require
breaking its performance first by encapsulating the entire function set
in a single thread which processes requests one at a time, whether they
block or not.
Once this is accomplished individual VFS devices, starting with the
block conversion devices (VN, MD, etc) and ending with the filesystems
(UFS, etc) can be 'asynchronized'. The asynchronizing will require a
huge amount of work.
I'm probably not going to bother trying to remove the MP lock until
after DEV, VFS, VM, and KMEM have been fixed. It's far more important
to maintain a stable system for development while these crucial
subsystems are being worked on. One reason why I decided to integrate
MP lock manipulation in the LWKT scheduler (even though the LWKT subsystem
does not itself need the MP lock to operate) is because I know I am going
to be saddled with it for a long time and I might as well make it as
painless as possible.
-Matt
Matthew Dillon
<dil...@backplane.com>
_______________________________________________
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
|