the vanilla ones. They are supposed to be identical to
{GENERIC,INSTALL}, apart from the different ncr5380 driver.
Instead of re-sync'ing, use a new feature of configure and just disable
the ncrscsi driver.
(Approved by Allen Briggs)
stack.
Fixes the "booting from disk memory corruption bug" which was a result
of pmap_extract silently failing against a scsipi_xfer data area allocat-
ed on kernel stack in _bus_dmamap_load_buffer
it, not the mtime of the file itself. This fixes the problems exposed when
unpacking software under a tmpfs and trying to build it because dependencies
were not calculated properly (e.g. autoconf 2.60 as reported by tls@).
I didn't know what header to put the prototype in, so it's both in
i386/mem.c and amd64/mem.c; probably can be moved later.
Tested on amd64, assumed working on i386. :)
yamt@ okay
If we already have an entry, we only print a message mentioning it if the
fingerprints mismatch; that may indicate a security issue.
If the fingerprints match, there's a good chance it's the same file
appearing multiple times as a hard-link, in which case print a message
only if the verbose level is 1 or more.
This should make 3c575CT work and fix following PRs:
kern/12965: 3com 575CT does not work
port-i386/16295: Problems in pci routing table and ex0 (3c575c-tx) networking
- remove an empty statement in if() clause by inverting logic
- use KDASSERT(9) rather than #ifdef DEBUG + KASSERT(9)
- replace commented out M_WRITABLE() with !M_READONLY(9)
using a completely bogus heuristic to guess at one. This might cause FIFO
underruns in particularly exciting video modes, but it also makes more
boring ones work correctly.
The passed size doesn't mean anything really and can only help detect
corrupted configuration files, which should be done in userland anyway.
Note it's possible to trigger a kernel panic by passing a junk
pointer in the 'fingerprint' member of the parameters, but then again
that's true for anything that copies in data from a userland-supplied
pointer. And we have plenty of those.
At the moment, Veriexec only allows the super-user to open the pseudo
device, so it's ~okay. Maybe we should address that in copy(9) or
something?
