Questions about next PREVIEW
dillon at apollo.backplane.com
Thu Jul 28 21:21:03 PDT 2005
:I'm really getting excited seeing all the improvements, bug fixes, and
:streamlining that have gone into DFly so far since the last Preview. It seems
:the next one should be coming along soon, right?
:Will this require rebuilding ports as well? And what exciting things will we
:lowly UP workstation users see?
:Hoppiness is a good beer.
We are now just waiting on Joerg's stat work to slip. Even though the
old stat syscall will remain, ports will probably have to be rebuilt
from scratch to avoid mixing old and new. Joerg has a few other things
he wants to fit in but we'll see how long they take.
Going to 64 bit inodes is a necessary change. I would have liked to have
been able to avoid it, but we have to do it. We are fixing the link
count field (16->32 bits) as well. The 64 bit work is, of course, just
in HEAD(and soon Preview) and will not go into the 1.2.x release branch.
My focus for the last 2 months has been to stabilize SMP and networking,
and I believe I have accomplished that goal. All of our SMP testers
are now reporting far better stability then before. Most of the
bug fixes have been MFCd to the release branch and I will soon
bump the subversion to make it official.
Next up for me is to work on removing the MP lock from the network stack
and to finish up the journaling code. The network stack is now almost
totally isolated and MP safe, with only a few areas needing work.
The journaling code is in very good shape... the two-way protocol and
journaling restart support is implemented in the kernel and fully tested
now. Now userland support needs to be added for those protocols to
allow journals, even through long chains of pipes, to be seemlessly
restarted. Undo records to make a journal reversable also need to be
added. This is a much smaller TODO list then I had before!
I also intend to start a push to make buffer cache address 64-bit clean,
which basically entails changing the block number fields into 64 bit
offset fields. Not an easy job and with dire consequences if I get it
<dillon at xxxxxxxxxxxxx>
More information about the Users