cases, since we never did 64 bit a.out. now ldd on 32 bit a.out
at least tries to work, but fails (on sparc or sparc64, no idea yet
for x86) the same way that all dynamic a.out binaries fail.
This is done by adding the general ability to stuff non-SUSP data into
the end of the System Use field of a Directory Record, which required
some amount of rewriting of the SUSP support. I think the result is
at least as good as what came before, and I've fixed at least one bug
along the way. Tested against RISC OS 3.70 on my Risc PC.
Oh, why do we want it? It should allow us to make acorn{26,32} CDs that
can be booted directly from RISC OS without mucking around copying the
bootloader to a native filing system.
timeout capability to these drivers. Apparently no one has ever had
scsi devices that failed to complete a scsi operation in some fashion,
or at least no one has reported it as best I can remember. I've just
run into this situation and figured out that one disk would fail to
complete an I/O transaction and never timed out. Add the appropriate
timeout function to reset the controller and restart things.
The lkptpa was required for hp300 (where PA != VA)
to prepare a page PA == VA to turn on the MMU,
and it is not needed for mac68k which has PA == VA
mappings even in kernel text/data/bss. Tested on LC630.
attached earlier during boot, when initializing hypervisor.
This avoids the "unknown type console at xenbus0 id 0 not configured"
autoconf(9) messages, which are misleading during domU's boot.
See also http://mail-index.netbsd.org/port-xen/2009/01/05/msg004621.html
Ok by bouyer@ in private mail.
Use this on the IQ31244 to force a watchdog reset from the M41ST84
if it's been attached. The generic reset doesn't fully reset the
system whereas the RTC watchdog reset does.
"-Os might cause compiler bugs on sh3" comment was for egcs or gcc3.
"-Os" might be also safe, but use the same one with the default sh3 build
for now.
Briefly tested on (not emulated but real) dreamcast.
really be autogenerated, but seems it's generally not required by
stuff in rump and guessing the location of the appropriate genassym.cf
is difficult without a major consultation.
Thanks to Havard for spotting the build failure.
the System Use field with fewer then 28 bytes to spare, we were
remembering the wrong length for the System Use field and hence
emitting a corrupt directory entry. This could be triggered by trying
to build a filesystem containing a regular file with a 120-byte name.
Now we're a little more careful.
christos