The idea is that we only clear M_CANFASTFWD if an SPD exists
for the packet. Otherwise, it's safe to add a fast-forward
cache entry for the route.
To make this work properly, we invalidate the entire ipflow
cache if a fast-ipsec key is added or changed.
superfluous by Tsutsui-san's previous changes.
(this change differs slightly from that posted to port-mips@, as
mips_flushcache_allpvh should be compiled iff MIPS3_PLUS is defined and
MIPS3_L2CACHE_ABSENT should be removed from files.mips as well)
with the PROM. From Valeriy E. Ushakov. This is a hack, but as long as
we don't have a way to arrange for a proper VA layout on this machines
(i.e. beyound the PROM) it is needed.
pckbcintr_hard and pckbcintr_soft, which, together, do the same as
pckbcintr. The first is called from the interrupt handler, the second
from a softinterrupt at arbitrary protection level (lower or equal to
IPL_TTY). They pass data via a small ringbuffer.
The new functions are intended for platforms that, due to
hardware/firmware restrictions are not able to make pckbcintr called at
IPL_TTY, like Krups javastations. Using the monolithic pckbcintr on
these plattforms leads to the input handlers for the slot data to be
run at elevated priority, causing various race conditions.
and don't try the disklabel.
Allows to create a filesystem on a floppy again.
(It is arguably another bug that DIOCGDINFO returns nonsense
for floppies.)
and without Kerberos 4 & 5 (MKKERBEROS=no). Previously checkflist
complained of missing files.
* move kerberos- and kerberos 4-only files into new flists,
distrib/sets/lists/*/krb.*
* make the flist generators grok MKKERBEROS{,4} variables
* fix Makefiles which treat MKKERBEROS=no as MKKERBEROS5=no.
9 out of 10 experts agree that it is ludicrous to build w/
KERBEROS4 and w/o KERBEROS5.
* fix header files, also, which treat MKKERBEROS=no as MKKERBEROS5=no.
* omit some Kerberos-only subdirectories from the build as
MKKERBEROS{,4} indicate
(I acknowledge the sentiment that flists are the wrong way to go,
and that the makefiles should produce the metalog directly. That
sounds to me like the right way to go, but I am not prepared to do
revamp all the makefiles. While my approach is expedient, it fits
painlessly within the current build architecture until we are
delivered from flist purgatory, and it does not postpone our
delivery. Fair enough?)
martin