In article <200012261607.eBQG7Or00428@unixag-kl.fh-kl.de>,
 <jkunz@unixag-kl.fh-kl.de> wrote:
>On 26 Dec, Christian Groessler wrote:
>
>>>Any clues?  The config file implies that it should be possible to run
>>>Reno binaries on NetBSD/vax.
>> 
>> I also tried this (with 1.5) and it didn't work for me either. And
>> with the executables from the 4.3bsd quasijarus project file g
>As I know the compat option is not for running binarys. It adds some
>4.3BSD-Reno speciffic kernel functions. This it is intended for
>recompiling 4.3BSD-Reno programms under NetBSD.

The problem is essentially this: in the 4.3 days, the first field of 
the a.out format header (exec) was a longword, a_magic.  This usually
contained one of OMAGIC, NMAGIC or ZMAGIC (0407, 0410, 0413).  OMAGIC
was the old format from the PDP-11 days and not really used.  NMAGIC
was the new format that used read-only text segments which could be
shared, and ZMAGIC was like NMAGIC, but demand-paged.

Sometime between 4.3 and 4.4, the a_magic field was changed to the modern
a_midmag field which contains a machine-id field.  Because of this, 
4.3 era binaries look like a different architecture and so the kernel 
will refuse to execute them (and 'file' will mis-identify them).  So,
there is a kernel option, called COMPAT_NOMID, which tells the kernel to
execute those old-format binaries which have OMAGIC, NMAGIC or ZMAGIC in
the a_magic/a_midmag header.

Unfortunately, although NetBSD/vax allows this kernel option, the actual
code it enables never made it into the vax-dependent code (every port
of NetBSD which contains this code implements it separately in
/sys/arch/<arch>/<arch>/machdep.c).  It looks as though there is a hook
in /sys/arch/vax/vax/vm_machdep.c for the implementation of this code
to go... Over the weekend, I tried dropping in an implementation from
another architecture, but it didn't seem to have any effect (although 
due to the holiday, I really didn't have a change to examine why in 
depth).

Another approach, which will be my next step, I think, would be to simply
edit a Reno binary and replace its first longword with the value which
would be expected for a NetBSD/vax binary, and see if that works.  In
that case, the only big issues will be whether the file formats are 
compatible and if the Reno syscalls are implemented.

--Mirian