KERNBASE and VM_MAXUSER_ADDRESS.
Remove the useless include of opt_global.h, as noticed by netchild@ (the one
in arm/elf_trampoline.c is legit, because this file is compiled outside the
kernel, and doesn't use the standard CFLAGS).
whole the physical memory, cached, using 1MB section mappings. This reduces
the address space available for user processes a bit, but given the amount of
memory a typical arm machine has, it is not (yet) a big issue.
It then provides a uma_small_alloc() that works as it does for architectures
which have a direct mapping.
Originally, I had adopted sparc64's name, pmap_clear_write(), for the
function that is now pmap_remove_write(). However, this function is more
like pmap_remove_all() than like pmap_clear_modify() or
pmap_clear_reference(), hence, the name change.
The higher-level rationale behind this change is described in
src/sys/amd64/amd64/pmap.c revision 1.567. The short version is that I'm
trying to clean up and fix our support for execute access.
Reviewed by: marcel@ (ia64)
mark system calls as being MPSAFE:
- Stop conditionally acquiring Giant around system call invocations.
- Remove all of the 'M' prefixes from the master system call files.
- Remove support for the 'M' prefix from the script that generates the
syscall-related files from the master system call files.
- Don't explicitly set SYF_MPSAFE when registering nfssvc.
implementations and adjust some of the checks while I'm here:
- Add a new check to make sure we don't return from a syscall in a critical
section.
- Add a new explicit check before userret() to make sure we don't return
with any locks held. The advantage here is that we can include the
syscall number and name in syscall() whereas that info is not available
in userret().
- Drop the mtx_assert()'s of sched_lock and Giant. They are replaced by
the more general checks just added.
MFC after: 2 weeks
The core uart code expects the receive method to actually puts the
characters read into its buffers. For AT91, it's done in the ipend routine,
so also check if we have the alternate break sequence here.
MFC after: 3 days
Introduce framework to configure the multiplexed pins on boot.
Since the USART supprots RS-485 multidrop mode, it allows the
TX pins to float. However, for RS-232 operations, we don't
want these pins to float. Instead, they should be pulled up
to avoid mismatches. Linux does something similar when it
configures the TX lines. This implies that we also allow the
RX lines to float rather than be in the state they are left in
by the boot loader. Since they are input pins, I think that
this is the right thing to do.
Plus minor for our board.
