I looked through /usr/share/man/man2, and I guess most of it does look
pretty useless for writing games.  To be painfully honest, I think the
reason NetBSD-for-game-consoles seems appealing is that it seems like
video games _on game consoles_ are the only high-quality programs of
substantial size left standing these days.

Here are a few things that a game might need:

  o a tcp stack.  probably an IPv6 stack, since multiplayer games will
    require direct communication between consoles to reduce rtt, and
    fake NAT addresses cannot do this.

  o preemptive and prioritizable threads, which can be created by
    high-res timers.

  o SMP support (for future consoles with multiple cores per die)

  o a filesystem with mmap(..), demand loading, and madvise(..)

  o debugging tools, with breakpoints narrowable to a thread

  o support for these difficult-to-implement things on more than one
    console architecture

I think you make a good point in the angle of your approach: not
``what should we add for games?''  but ``what do we already have that
is useful for writing games?''  Not much, I guess.

still.  Debugging is a pretty big deal, and writing your game with
``overlays'' instead of demand-loading has got to be a royal pain.

also, even if the amount of code NetBSD eliminates is small, when the
skill set required to replace this code is sufficiently different from
that required by the rest of the game it could be disproportionately
expensive to replace (and maintain) NetBSD's share of a job.

particularly when this NetBSD-replacement cost is multiplied by
porting the game to n consoles: only a small part of the bulk of the
game is *n, while all of prospective NetBSD features like threads,
debuggers, and VM must be redone *n, perhaps even by n different
contracted developers each with intimate knowledge of one CPU.


It is somewhat fair to say that memory protection is a costly and
unnecessary feature on a single-application machine, but there are two
mitigating factors: 

  (1) it makes debugging easier when your program crashes in code that
      you wrote yourself, rather than in kernel code that you don't
      understand.

  (2) when all threads are in one process, there is no TLB-flushing,
      which dramatically reduces the traditional cost of memory
      protection.


I'm sorry if I'm belabouring this, or getting things wrong, or
promoting a bunch of blind-leading-blind babbling.  But, I think it's,
rather important.

I've participated in some discussions about switching from QNX to
Linux (or so-called ``RT/Linux''), and I found that the issues are
sometimes incompletely understood, no less by the people actually
using the tools than by mental-masturbatory ``enthusiasts'' like
myself.

People stick with the familiar.  The level of discourse in choosing a
new embedded platform can be no more advanced than that.  This is bad.
A NetBSD opportunity is thus:

 Step 1: arrange ahead of time for NetBSD to win an intelligent
         argument about embedded platforms.

 Step 2: advance the level of discourse about embedded OS's.

 Step 3: Profit.

This will allow NetBSD to prevail over underpowered alternatives like
vxWorks and eCos, or inefficient alternatives like QNX.


What is the deal on PS2 exports from Japan, anyway?  Is it against
Japanese law, or is Lik-Sang really going to follow through and stock
some, or both?

-- 
Klar, Entlueftung, Zuendung, Vorstufe, Hauptstufe.