mappings for CADDR1 and CADDR2, unless we're built w/ -DDEBUG. Since
these addresses are only used in these routines, we can "lazily invalidate"
them by just using them again. This makes these routines a teeny bit faster,
as it saves 1 or 2 TBIS's per call.
Suggested by Leo Weppelman <leo@netbsd.org>.
pmap, forget all of the mappings for the user address space for that pmap.
This causes the PT pages to be freed so that they can be reclaimed by the
VM system. [*]
[*] Actually, in the current implementation, it merely causes the wiring
count on the PT pages to drop to 0, which allows them to be reclaimed by
the pagedaemon. Handling of PT pages needs to be completely rewritten.
pmap_remove() for the temporary addresses. This is completely unnecessary
as the temps are used ONLY for these routines, and we have better control
over the mapping by manipulating the PTE ourself. On VAC systems, cache-
inhibit the mapping to prevent wasting a cache load.
These routines are now significantly faster.
Add a DIAGNOSTIC check in pmap_enter() for kernel pmap and (CADDR1 or CADDR2);
nothing should be adding mappings there via that interface.
- returned EOPNOTSUPP rather than -1.
- no check for negative offset.
many of these fix potential security problems in these drivers.
XXX XXX XXX
the d_mmap cdev routine should be changed to have a prototype like:
paddr_t (*d_mmap) __P((dev_t, off_t, int));
by someone!
- cpu_set_kpc() now takes void *arg third argument, passed to the
entry point.
- cpu_fork() allows parent to be non-curproc iff parent is proc0.
When forking non-curproc, assume its state has already been saved.
- Adjust various pieces of machine-dependent code to account of all of this.
-sys/lib/libkern builds as library per default (as it was documented all
the time)
-ports able to LKM set "KERN_AS=obj" explicitely in their Makefiles
(for now; should depend on actual "option LKM" or -better- functions
included for LKM use should be pulled in by a stub)
-always link libcompat before libkern - libkern stuff can be referred to
by libcompat, but not the other way
which require special handling, e.g. sigreturn on m68k.
This differs from the old sigreturn trap in that we require the syscall
number to be in register d0, just like the regular syscall entry point.
This will allow sigreturn to be versioned in the future without the need
to allocate another trap vector.
u-area in machine-dependent code. Instead, call exit2() to schedule
the reaper to free them for us, once it is safe to do so (i.e. we are
no longer running on the dead proc's vmspace and stack).
interrupts; if there's an interrupt pending (i.e. because the user pressed
a key or moved his mice while the kernel was being loaded), the interrupt
handler may safely be run. Fixes PR port-hp300/5397.
reading the DIO device ID at select code 7, but rather hard-wire the ID
to the IHPIB ID. This prevents us reading what might look like a valid
ID to another device when IHPIB is present. (IHPIB doesn't always return
a correct device ID, grumble.)
as with user-land programs, include files are installed by each directory
in the tree that has includes to install. (This allows more flexibility
as to what gets installed, makes 'partial installs' easier, and gives us
more options as to which machines' includes get installed at any given
time.) The old SYS_INCLUDES={symlinks,copies} behaviours are _both_
still supported, though at least one bug in the 'symlinks' case is
fixed by this change. Include files can't be build before installation,
so directories that have includes as targets (e.g. dev/pci) have to move
those targets into a different Makefile.
a HAVE_GCC28 check-variable that can now be used to add other gcc-2.8
flags in cases where they may be useful, or to remove gcc 2.7.2 "bug
workaround" flags.)
we were in ledcontrol(), the heartbeat twinkler would just punt on
updating the LED even though it had already updated the status. (This
was broken in v1.73 of locore.s).
Rather than resurrect the old code, simplify ledcontrol() and don't
bother with mutual exclusion. As mentioned by the comments describing
this function, we really don't need to be that precise. We do, however,
want to guarantee instructions that modify the status variable directly,
so the function is now primarily inline assembly.
thorpej