Development stalling?

[Dmitri Nikulin]

Reading through the diary and mailing list archives, there's evidence
AMD64 support was planned years ago, but besides some files gathering
dust, lacking even a GENERIC, it doesn't seem to have gotten anywhere.
I also heard Xen support was intended but never heard about it again.

What happened to AMD64? The toolchain is there, the base code is
there... is it the busdma-ification that's holding things up? It
appears as though the only commits in the last few months are the
great inner restructuring, documentation and thread_xu, with some
fixes as bugs crop up.

If there's anything for a not-yet-kernel developer to do, I'd like to
help out, since I have a lot of free time lately and a great interest
in the continued rise of DragonFly's utility. Any simple kernel tasks
would be great. I have an X2 4400+ Toledo on an Asus A8V Deluxe so I
can do SMP and AMD64 testing (machine currently runs NetBSD-current).
I already know this machine can run DragonFly 1.4, because it did for
a few days. First order of duty would be to reproduce my pf panic and
get that fixed.

I could additionally offer some form of stress and performance
testing, which would form a regression testing base. At least I
haven't seen any formal QA references for DragonFly, and it could be a
compelling reason for people to switch from less stable systems
(chiefly Linux). Running these tests on each -PREVIEW slip could
indicate if anything was broken. They could be anything from weeding
out race conditions by doing unholy things a few million times per
second in threaded environments, to stacking disturbing numbers of
nullfs mounts over a memory disk and performing intensive tasks on
them. Other things like sane VFS behavior (which has had a lot of bugs
in the past) could be verified by running tailored shell scripts and
ensuring sane output.

Out of interest, what other DragonFly projects have been delayed or
abandoned? Are too many developers busy with their own lives now?

  -- Dmitri Nikulin