Uh, why not do diskless-workstation dumps via TFTP?  Why use NFS if
all you want is to copy bits from main memory into a known file on
disk? If TFTP is good enough for booting, it should be good enough for
a kernel dump, too; and it avoids all the NFS and krpc code.  (it
could even use special-case UDP and IP code, if that turns out to be
better.) 

>>In one sense, it's not.  In another, the way dumps are done to disk typically
>>involves a relatively short code path... put NFS in there, and suddenly you
>>involve the krpc code, udp code, ip code, ethernet drivers (which may play
>>tricky mbuf games), buffer cache, etc.

>I see your point here...but it still can be done.  To use a really
>lousy example, ULTRIX supports dumping over the network.

Oh, it's not *that* lousy.  Ultrix is arguably the finest 4.2BSD
system there ever was.  But even with all the enhancements, it's still
a pre-4.3BSD system, and it shows. 

Back to the 1990s: my guess is that supporting dumps from diskless
workstations is *required* by a commerical vendor who offers customer
support. Suppose the standard diagnostic procedure for kernel crashes is to
have the customer is to send a kernel config file (or kernel) and
savecore output to the support centre.  

You pretty much *have* to support kernel coredumps from diskless
workstations, or you can't offer support to support diskless
workstations at all.  This is of course much easier with block-IO
abstractions like ND, RVD, VAXcluster I/O, or TFTP, than with a
filesystem-abstraction like NFS.

If we decide to support dumps from diskless workstations, can we
at least _consider_ dumping via TFTP as an alternative to NFS?