*-sushi-* packages.
Suggested by Allen Barret in PR misc/16900:
>$ grep base-sysutil distrib/sets/lists/base/mi | grep sushi | wc -l
> 288
>$ grep base-sysutil distrib/sets/lists/base/mi | grep -v sushi | wc -l
> 136
>
>In a future where syspkgs are useful, it seems likely that some
>people will want to avoid installing sushi, while others will want to
>be able to upgrade sushi without upgrading the entire system. Several
>small subsystems, including cron and lpr, have their own syspkg sets,
>and it seems reasonable to do the same for the sushi subsystem.
- bbinfo_params:
- replace "int littleendian" with "bbinfo_endian endian"
- add comments
- shared_bbinfo_clearboot():
- add callback method to shared_bbinfo_clearboot()
- don't clear from 0..headeroffset; use a callback to do that
- add news68k and newsmips support.
From Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, with a rework by me to
take advantage of the new shared_bbinfo_clearboot() callback.
(XXX: untested yet)
column gets a trailing "," if there's more entries to come.
- if getmachines() or getfstypes() is called with 3 NULL params, just
print the list of supported items.
- in usage(), call getmachines() and getfstypes() with 3 NULL params.
(i got sick of typing "installboot -m asdf" to get a list of
supported machines during testing :)
than current one; this is expected (even documented) behaviour of the
new system call
This fixes the endless loop when reading directories on NFS, though
applications won't see all directory entries due to different problem.
Fix by Matthias Scheler and Charles Hannum.
boot loader image. Installboot can modify the default command in the
first-stage bootblocks, which will have no effect. Copy the default command
from the first-stage bootblock into the second-stage bootloader so modifying
the commandline with installboot actually works again.
which are IIcx and IIx machines with not much RAM, respectively.
The PUMA config is configured somewhat optimally for one of Allen's
Quadras but doesn't do anything special as compared to SMALLRAM.
to use a pc-relative jump. Which is definitely not what is needed in the
relocation code!
This is new in the current assembler apparantly. None of the kernels build
after my latest upgrade were able to boot... What else is lurking!
