DragonFly kernel List (threaded) for 2007-06
Re: implemented features (Re: Decision time....)
I'll just say here that my particular psychosis when it comes to
doing a project is, "if it's going to be done, it has to be done right."
Even I recognize that this is not always the best path, but being able
to enjoy the work is a major reason why I do it.
There are fifty things I would love to see in the kernel, including
finishing off the SMP support and doing an AMD64 port. But many of
those are things I would rather other developers do, particularly
the SMP work for the network protocol stacks because its like 95% done
already. They are important, but if I spend all my time there then we
won't have a new filesystem at the end of the year. Having a new
filesystem is a big ticket item for the project.
In order to be able to work on the bits that are most important
to my vision of the project I have to prioritize. Right now my
priorities are: GPT support, a new filesystem, and the clustering goals.
I am very big on supporting other developer's work. I'm there to help
implement the supporting infrastructure and I am there to help finish
off mostly completed work (such as NATA), and make it production-ready.
I've just about handed SMP to people on a platter but so far no
developers have taken up the baton on that one (and as I said, the
filesystem is more important right now).
Well, not everything works out the way one hopes. But I will remind the
community that production stability is also extremely important to the
project and there are certain pieces of infrastructure work, like SMP,
that are very hard to do right and still have a stable system at the
end of it (I think any FreeBSD developer can attest to that!). There's
no point having a feature if the result is an unstable system. We
have maintained most excellent stability in our releases and I think
things can only get better as time passes.
Consider for a moment that in one fell swoop just a short while ago
(Feb-Mar), Simon and Thomas did an extremely major LWP commit that
changed infrastructure in the kernel's handling of processes and
signals and completed a MAJOR separation of the process structure.
It went in so smoothly that there was nary a whimper on the lists.
In fact, it went in so smoothly that I didn't even realize just how
extensive the changes were until a few weeks later! Process/LWP
separation was a major infrastructure requirement for being able to
make all the related code MP safe. And maybe, just maybe, we now
have two more developers who understand the kernel core well enough
to do some SMP work (hint hint!) too.
There is an excitement factor, too. Who'd-a-thought one could switch
libthread_xu and libc_r on the fly? Now we can!
In anycase, don't discount infrastructure work. Infrastructure work
turns out to be a major enabling factor for future development AND
for code longevity and stability. We've reaped many benefits from
the approach that aren't readily apparent to an end-user because the
psychosis that an end-user has is that the system 'not crash'... but
we developers know that making a system 'not crash' is a lot harder
then it seems.