Well, I'll give you my 5-second opinion.

    What I am not worried about:

        * Developer interest has always increased slowly and continues to
          do so.  I'd be interested in commit statistics but my gut feeling,
          from NOT having to push into subsystems that I used to have to
          push into, is that more developers are working on more of the
          critical infrastructure.

        * More developers are doing the 'harder' aspects of kernel
          development rather then just me.  This is very, very important.

        * Ports and packages.  This was a huge worry of mine at the beginning
          of the project.  I no longer worry about it.

    What I am worried about:

        * The big-ticket items that we have traditionally compared ourselves
          against, SMP primarily, have developed slowly, primarily because
          up until recently I was the only person working on it.

          It an issue of man-hours more then anything else.  FreeBSD simply
          has more developers working on SMP then we do.

          We have the infrastructure and the abstraction, we now need to get
          down to the brass balls and finish it.

        * I really want to see someone take up the ball on getting the 
          network stack MP safe.  It's important to the project but I can't
          do that and HAMMER at the same time.  It's the easiest thing
          to make MP safe in the project.

        * Similarly with AMD64.  We need it.  I've developed the
          infrastructure separation required and we even have a fully
          virtualized kernel (vkernel) which demonstratres the infrastructure
          separation.  Most of the generic kernel code can easily support
          a 64 bit architecture.  The compiler supports it.  It's a project
          waiting for someone to take up the ball.

        * Our interrupt routing subsystem really needs a major upgrade.
          (i.e. a major port from FreeBSD).

    Where I think the future is:

        * SMP, Storage, and SSI.  Real time mirroring at the logical level.
          HAMMER is a major component for the storage, SSI, and mirroring
          components, and I believe HAMMER will be a large interest magnet.

        Our project goals have not changed, but if I had it all to do over
        again I would have started work on HAMMER much earlier then I did.

        I spent more time then I should have perfecting the low level
        infrastructure, trying to build a base upon which all the other
        work could occur.

                                                -Matt

Reply via email to