. move mfs-specific struct, constants to mfs/, so
mfs-specific, on-disk format structs and consts are
fully isolated from generic structs and functions
. removes de and readfs utils
- this function returns a ritcher description of available memory
- is ACPI compliant, ACPI data structures are excluded from free
memory list
- available memory exported to Minix in a backwards compatible manner
- fallback to the old method if this function not available (old
hardware)
-Makefile updates
-Update mkdep
-Build fixes/warning cleanups for some programs
-Restore leading underscores on global syms in kernel asm files
-Increase ramdisk size
boot is a normal binary with a.out again. use 'cdbootblock,' a CDBOOT
variant of bootblock, both from bootblock.s, as the first boot image
that then loads boot, exactly like the bootblock loads boot when booting
from harddisk. the sector numbers (2048 byte iso sectors) are patched in
by writeisofs, like installboot does for bootblock. bootblock unchanged.
-Convert the include directory over to using bsdmake
syntax
-Update/add mkfiles
-Modify install(1) so that it can create symlinks
-Update makefiles to use new install(1) options
-Rename /usr/include/ibm to /usr/include/i386
-Create /usr/include/machine symlink to arch header files
-Move vm_i386.h to its new home in the /usr/include/i386
-Update source files to #include the header files at their
new homes.
-Add new gnu-includes target for building GCC headers
Some cases were fixed by declaring the function void, others were fixed
by adding a return <value> statement, thereby avoiding potentially
incorrect behavior (usually in error handling).
Some enum correctness in boot.c.
ow that the image has grown beyond the 1.44M that fits on a floppy.
(previously, the floppy emulation mode was used for cd's.)
the boot cd now uses 'no emulation mode,' where an image is provided on
the cd that is loaded and executed directly. this is the boot monitor.
in order to make this work (the entry point is the same as where the
image is loaded, and the boot monitor needs its a.out header too) and
keep compatability with the same code being used for regular booting, i
prepended 16 bytes that jumps over its header so execution can start
there.
to be able to read the CD (mostly in order to read the boot image),
boot has to use the already present 'extended read' call, but address
the CD using 2k sectors.
- only print a line for every boot process if 'verbose' variable set to
nonzero; reason: with serial output, the long output
significantly slows down frequent reboots, and causes 'scroll damage'
that in some cases is pretty bad. also the verbose output doesn't tell
you the one thing you might want to know about a process: how much memory
is it using? or how much memory is everything using?
- short format does print out total memory allocated for processes