Questions about next PREVIEW

Matthew Dillon 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?
:
:Jonathon McKitrick
:--
: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
    wrong.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Users mailing list