to determine if a fault is read or write, make sure tf->tf_pc is 32-bit
aligned before dereferencing it.
Otherwise, deliver an illegal instruction signal to the process. We don't
support execution of Thumb code at this time.
This reloads the entire EEPROM, not just the MAC address, which can
cause problems for the host PCI bus under certain circumstances. The
chip already loads the EEPROM at powerup/reset anyway.
XXX: This probably applies to the other Rhine variants too, but I don't
have a data sheet to confirm this behaviour.
1) make sure Mach servers will not work on data beyond the end of the
request message buffer.
2) make sure that on copying out the reply message buffer, we will not
leak kernel data located after the buffer.
3) make sure that the server will not overwrite memory beyond the end
of the reply message buffer. That check is the responsability of the
server, there is just a DIAGNOSTIC test to check everything is in
good shape. All currently implemented servers in NetBSD have been
modified to check for this condition
While we are here, build the mach services table (formerly in mach_namemap.c)
and the services prototypes automatically from mach_services.master, just
as this is done for system calls.
The next step would be to fold the message formats in the mach_services.master
file, but this tends to be difficult, as some messages are quite long and
complex.
* if loading from cdrom, assume we're performing an install and
fix up bootpath/kernel to load the proper install kernel.
* maximum filename length in volume header is eight characters.
Change boot.elf to ip2xboot, boot.ip32 to ip3xboot, and boot
to aoutboot (which matches kernel naming scheme as well).
copyin() or copyout().
uvm_useracc() tells us whether the mapping permissions allow access to
the desired part of an address space, and many callers assume that
this is the same as knowing whether an attempt to access that part of
the address space will succeed. however, access to user space can
fail for reasons other than insufficient permission, most notably that
paging in any non-resident data can fail due to i/o errors. most of
the callers of uvm_useracc() make the above incorrect assumption. the
rest are all misguided optimizations, which optimize for the case
where an operation will fail. we'd rather optimize for operations
succeeding, in which case we should just attempt the access and handle
failures due to insufficient permissions the same way we handle i/o
errors. since there appear to be no good uses of uvm_useracc(), we'll
just remove it.
lukem