note:  these are comments by another (long time) netbsd/sparc user,
come developer.

    -- NetBSD mounts `/dev/sd0a' on `/', regardless of what drive it was booted
       from.  I expected, and would have preferred, the SunOS behavior of
       mounting the root file system from the `a' partition on the boot device.

this is most likely because the kernel was configured with:

config netbsd root on sd0 swap on sd0

if

config netbsd swap generic

worked, then you wouldn't have this problem.  (it *will* work soon,
or maybe even now, but i don't think so).
   
    -- I have to say that I don't at all understand the purpose of numbering the
       SCSI disks the way NetBSD does.  The prospect of either changing the
       jumpers on my other drives, or globally editing /etc/fstab, whenever I add
       or remove a disk other than the one with the highest SCSI ID doesn't
       appeal to me.  I know, I can turn it off if I want, but what I'm getting
       at is that I think it should be off in the distributed installation
       kernel, which should have, hardwired, either the standard SunOS mappings
       (0->3, 1->1, 2->2, 3->0) or direct mappings.  As it was, I used the
       `id3_scsi' kernel and wound up with 0->3, 1->0, 2->1, 3->2 which was
       unexpected to say the least.

this is related to the above;  it "works" under sunos because the
kernel is generally compiled with hardwired mappings from 3120 to
0123.  put this in your config file:

sd0     at scsibus? target 3 drive ?
sd1     at scsibus? target 1 drive ?
sd2     at scsibus? target 2 drive ?
sd3     at scsibus? target 0 drive ?

in place of

sd*     at scsibus? target ? drive ?

and you get the "sunos" like mappings.

    -- The installation instructions say nothing about `pwd_mkdb'!  I had to do
       some sleuthing to find this sucker.  The instructions should really say
       specifically how to install one's SunOS `passwd' file:
   
   [ ... ]
         [Perhaps a `sed' script or something could be supplied to do this?]

that would be nice;  do you want to write it ?

            # pwd_mkdb passwd.tmp
            # pwd_mkdb -p master.passwd
   
         The first execution of `pwd_mkdb' updates `/etc/spwd.db'; the second
         regenerates the SunOS-style password file (minus the encrypted
         passwords) into `/etc/passwd', where SunOS executables may expect to
         find it.

you should be using vipw(8) for editing the password database.
   
    -- It would be nice if NetBSD came with a precompiled version of `tcsh',
       since the SunOS executable doesn't work (yet?).

it doesn't ?  i might look at this..
   
    -- To run many SunOS executables, it is necessary to
   
         # ld -s /usr/libexec/ld.so /usr/lib
   
       At least, I guess this is the right thing to do -- it seems to work.

try:  man compat_sunos

i hope oneday to fix this and make the sunos compat code look in
/emul/sunos before looking in / -- like it does for svr4 and linux,
but this is not a high priority for me (getting the svr4 compat
working is).
   
    -- Q: What is the command, corresponding to `pstat -s', to see how much swap
       space is available?

um, pstat -s ?

splode ~> pstat -s
Device      1024-blocks     Used    Avail Capacity  Type
/dev/sd0b         50400    23556    26844    47%    Interleaved
/dev/sd1b             0  *** not available for swapping ***
   
   After I got the system running, it became evident that the SunOS binary
   compatibility is not quite where I need it to be to permanently change over to
   NetBSD.  I tried to start my SunOS X11R5, but `xinit' got a bad system call
   error.  Okay, I *can* rebuild X11R5, though I don't relish the thought, but I
   also have some executables I can't rebuild, notably Franz Allegro Common Lisp
   (which says "Can't allocate memory" when I try to run it).  And so I have some
   questions.  What is the degree of commitment to the SunOS compatibility?  Is
   100% compatibility a goal, or even possible?  When I try an executable and it
   doesn't work, how can I get more information about what went wrong?  Do I have
   any hope of fixing the problem or will that take a wizard?  Are any of these
   problems likely to have been fixed already in the latest version?

there is a pre-built X11R6 on the netbsd ftp sites;  it might only work
under -current, however, as i only have one machine and i tend to keep
at -current most of the time.  if you get X11R6 patchlevel 11, and apply
the small patch i've made available with the binary, you should be able
to build it out-of-box, modulo a small bug in xdm where it doesn't call
setlogin(), and thus getlogin() returns "root" always..
   
   [Oh -- I just discovered the X11R6 binary on Gatekeeper, which by the way is
   where I got everything.  Okay, I'll use that.]

oops.  that will teach me to answer before reading on  :-)

if you use xdm, i would still fix that anyway.  if you can't find the
patch, email me and i'll send it to you.

.mrg.