major code cleanup esp. types used. Also cleanup up a major BUG that for
some odd reason worked :-/ makes me puzzled. It signifies that there might
be copies around in physical space of the DRAM ??? and thus its function
was motherboard dependent? It must have been old cruft from before the
cleanup of the relocation engine.
/*
* The size of the code/data to be moved is not `end - rmbase' but
* `__bss_start__ - rmbase' for the module is loaded into RISC OS
* based on the filesize where as NetBSD doesn't have to include all
* the bss space into the file itself. In some odd cases the
* relocatable module area can be smaller than the module + bss and
* thus bomb out.
*/
cd ${KERNSRCDIR}/${KERNARCHDIR}/compile && ${PRINTOBJDIR}
This is far simpler than the previous system, and more robust with
objdirs built via BSDOBJDIR.
The previous method of finding KERNOBJDIR when using BSDOBJDIR by
referencing _SRC_TOP_OBJ_ from another directory was extremely
fragile due to the depth first tree walk by <bsd.subdir.mk>, and
the caching of _SRC_TOP_OBJ_ (with MAKEOVERRIDES) which would be
empty on the *first* pass to create fresh objdirs.
This change requires adding sys/arch/*/compile/Makefile to create
the objdir in that directory, and descending into arch/*/compile
from arch/*/Makefile. Remove the now-unnecessary .keep_me files
whilst here.
Per lengthy discussion with Andrew Brown.
got wrong when no VRAM was there.
Placing the video DRAM in front of the kernel is OK when its 1Mb since the
kernel wants to be on a Mb boundary. Placing the video DRAM in the last
SIMM bank at the front is also OK unless there is just one SIMM and just one
bank; then it got in the way again!
Solution is to put the DRAM at the end of the SIMM instead of the beginning!
This however can result in the non 16 kb alignment of the top of physical
RAM where the temporary L1 page tables are situated. If its not 16 kb aligned
then move the L1 page table address down and down until it is 16 kb aligned.
This memory will be reused later on anyway.
What to do when we really support changing screensizes... see it as a max?
or use a different sceme alltogether? It might not even be a bootloader
problem then allthough its memory is not showing up in the DRAM/VRAM
block counts wich needs to be fixed one day.
platform. It features far better support for newer architectures and is
fully rewritten in C and compile-able under NetBSD.
Since it shares code with `boot26' for Acorn26 merging the common parts is
likely to be next on the list.
- disk_unbusy() gets a new parameter to tell the IO direction.
- struct disk_sysctl gets 4 new members for read/write bytes/transfers.
when processing hw.diskstats, add the read&write bytes/transfers for
the old combined stats to attempt to keep backwards compatibility.
unfortunately, due to multiple bugs, this will cause new kernels and old
vmstat/iostat/systat programs to fail. however, the next time this is
change it will not fail again.
this is just the kernel portion.
kqueue provides a stateful and efficient event notification framework
currently supported events include socket, file, directory, fifo,
pipe, tty and device changes, and monitoring of processes and signals
kqueue is supported by all writable filesystems in NetBSD tree
(with exception of Coda) and all device drivers supporting poll(2)
based on work done by Jonathan Lemon for FreeBSD
initial NetBSD port done by Luke Mewburn and Jason Thorpe
in question, whereas the ARM code was using it to hold the model
identification. To fix this, rename:
ci_cpuid -> ci_arm_cpuid
ci_cputype -> ci_arm_cputype (for consistency)
ci_cpurev -> ci_arm_cpurev (ditto)
ci_cpunum -> ci_cpuid
This makes top(1) give correct CPU numbers in its "STATE" column (all 0 for
now).
invalidation after every lock to ensure that changes made by other CPUs are
visible. This has nasty performance implications, but it does allow my
Hydrated Risc PC to run printf() on all its CPUs at once without corrupting
the message buffer.
and boot multi-user on a single-processor machine. Many of these changes
are wildly inappropriate for actual multi-processor operation, and correcting
this will be my next task.
bouyer