> Yes, but you cannot load the NetBSD kernel directly with mop; you must
> load it from the boot program, and the boot program doesn't have any 
> routines for qe ethernet.

Illogic. The netboot routies will load anything that fits the protocal.
It's been a while, if memory serves that means any program that is up to 64k 
in size <maybe larger>. Once loaded it does not have to even acknowledge how 
it got there.  Typically in VMS enviornments the mop loads a loader, that
loader knows a higher protocal appropriate for tha task or adaquate to load 
something big like VMS itself.

So assuming you have a vax running vms, you could for all intents make the 
mop load any .exe you care to the target.  I may add the target does not 
even have to be a vax!  A netbsd root that knows nothing of the qe but can 
write itself to floppy or other media could be such an .exe.  This takes
the limitation that netbsd does not support mop boot in itself as a host or 
target and limits it to only the target.  No oncew the root is in if it has 
the qe driver there should be no reason that a remote filesystem cannot be 
supported from a netbsd host.  This would mean a VAXVMS host, netbsd or inux 
host and the target on the local "net".  This would make migration 
<propagation> far easier for vs2000, MVII, 3100, 3400, 3600 and others. I 
may point out for that list there are only a few different <deqna, delqa, 
lance> ethernet devices where as mass storage varies widely.

I may not be knowlegeable of unix but certain OS assumptions still apply.
One is that in defining an OS the device drivers are critical parts and 
NETBSD from what I see has a good core but the base devices are really weak.
Granted for the vax world there are more mass storage devices than asprin
but, some devices have strong commonality should be supported and for the 
Q-bus machines that's the DEQNA<delqa> and for non-Q the lance.  Then the 
mass storage problem can be addresses by looking at those that are common to 
all or most of those or at least can be used in any.  The RQDX3 (qbus) for 
disks and SCSI along with MSCP.  Granted these are old devices but they are 
common.

Another area of pain is the assumption that someone launching netbsd has a 
unix box already.  If you don't your dead in the water as anything else 
is at most usable to _maybe_ create media and _maybe_ compile code.  The 
latter is loaded with assumptions like having a compiler and library that is 
compatable.  

I may have missed something but I see holes.

Allison