> This concerns me slightly, as outlined above. Perhaps Mark or Neil can
> allay my fears/concerns ?

I'm not Mark or Neil, and don't speak for Causality.  I'm part of the
group at DEC that's developing the Digital Network Appliance Reference
Design (DNARD, pronounced "Shark").  For readers who don't know what
the Shark is, take a look at: http://www.digital.com/semiconductor/dna.htm .

In a nutshell, we've built a StrongARM-based Network Computer system
board and are running a (hacked) version of NetBSD/arm32 on it.  We're
a commercial operation using and developing NetBSD/arm32, and we've
had a fair amount of interaction with the folks at Causality.  Some of
your concerns struck home with me and with other members of the group,
so I thought I'd post a brief message about _our_ plans with respect
to NetBSD (and with respect to NetBSD/arm32 in particular).


We're strongly committed to making sure that the sources to the base
operating system running on the Shark are available and integrated
into the NetBSD master source tree as soon as is reasonably possible.
(Yes, the source and design information release date on the web page
keeps being pushed back, but the information _will_ be available as
soon as is reasonably possible.  There's so much to do, and so little
time!)

We're also strongly committed to making sure that those sources
perform well on (at minimum) the hardware we're developing.  If the
software doesn't perform well, the hardware doesn't look very good!
Since the Shark is built around the StrongARM, we need and want good
performance on StrongARM chips.  Of course, because we're going to be
giving away all of our modifications to the base OS software, any
improvements we make in that area will be available.

As soon as Mark is ready, we're going to ship him a set of our changes
to the arm32 port, so that we can get mostly synchronized with the
NetBSD-current source tree.  Once most of the Shark-specific
modifications are in the NetBSD master source tree, we plan to be
syncing with the publicly-available NetBSD code base, using it as
our development base, and releasing diffs relative to it.  We will
_not_ be working from a private code base; whatever base we're working
from will be available to the world.

Finally, I thought I'd mention that the folks here working on the
Shark definitely appreciate the work that the public has put into
NetBSD/arm32 development.  Without the work of the NetBSD community,
our work developing the Shark would have been much, much harder, or
might have taken a different path entirely.


chris