Date: Fri, 1 Dec 2006 10:39:15 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Robert Watson <rwatson@freebsd.org>, Ivan Voras <ivoras@fer.hr>, freebsd-arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <200612011839.kB1IdFZO067817@apollo.backplane.com> References: <3931.1164968488@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:So, like, why don't you work on that, instead of annoying us with your
:long lectures about how "The World Shall Be Ordered According To Me" ?
:
:Poul-Henning
Because, fortunately, the lives of DragonFly developers aren't governed
by big-dick contests from people who clearly have no clue what DragonFly
is all about. I said from the outset that we wouldn't be taking
shortcuts to 'compete' with other distributions, and we haven't. The
BGL will be turned off in the networking threads when we are good and
ready to do it. #1 on my priority list is achieving the major goals
of the project and keeping the system stable while we do it. MP is only
part of those goals. A big part, but still only a part. Frankly, I
think we have done a better job on the stability front then you guys
have.
My personal agenda for the January release is to finish the userland
kernel support - basically features which allow a kernel to be built
as a userland application and to control independant VM spaces (its 'user'
processes) with the help of the real kernel. Userland kernels are linked
against libc and the kernel APIs have to be simple enough and bullet
proof enough for it to work as a non-root userland application. The
intent is to be able to do so with as little supporting overhead from
the real kernel as possible. This is going to be a very cool feature,
similar in scope to usermode linux, and it is also a necessary prereq
to reduce engineering cycle times for development of the big ticket items
next year.
My goals for all of next year are to make good progress on the two
biggest ticket items in the DragonFly goal list -- SYSLINK and CCMS.
Yes, we've finally reached the point where it is possible to actually
start work on these items, and I'm very excited about it! SYSLINK is
the core protocol that will be used to communicate between hosts in
a cluster, and CCMS is the core MESI+ cache coherency algorithm
that will guarentee full coherency between hosts in a cluster. A
staggering amount of infrastructure work on pre-existing subsystems,
such as the buffer and namecaches, VOP API, etc, was required to get
ready for the SYSLINK and CCMS work. Neither will work very well if we
have to push into the VFS every time we want to do an I/O or stat() a
file, after all. There is still a ton more work to do, including
and most especially giving higher kernel layers direct access to the
buffer cache so as to be able to bypass the VFS in the cache case (this
is also why the namecache topology was rewritten, and is already
the case for lookup operations).
In anycase, I am very happy to say that we have made extremely good
progress on all fronts. Of all the original subsystems inherited
from FreeBSD we are basically down to just the VM system, namecache,
vnode(1), and packet filter APIs with regards to the MP work, and work
is progressing on LWP style (user) threading. Dozens of major
subsystems were rewritten this year, I'll have to go through the commit
logs to get a complete list. Things like the buffer cache, VM page
cache, kernel user process scheduler, file descriptor handling, and
so on and so forth.
(note 1): The vnode ABI is a different ball of wax. Both MP and CCMS
have to be tightly integrated because CCMS will be used to control
coherent access on a byte-range basis for all I/O, the intent is to
allow the execution of multiple modifying operations on the same vnode
to occur in parallel. Achieving this will require a complete rewrite
of the vnode's current lockmgr-centric API.
That's what I'm doing. I am also happy to say that we have some
wonderful developers doing a great deal of work on DragonFly, such as
the PkgSrc integration, WiFi and other network infrastructure and drivers,
networking, web site, documentation, bug reporting systems, and other big
pieces that are needed to make a real platform out of DragonFly. I
provide enabling infrastructure to support the other work and I work on
the major project goals. I couldn't do it without all the help I'm
getting.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612011839.kB1IdFZO067817>