While here, reduce some diffs arising from ordering and formatting
between these architectures.
Only difference between evbarm and aarch64 now is /dev/vchiq. Not
sure offhand if it makes sense on aarch64 or only 32-bit Arm.
PR port-amd64/58093: /dev/efi missing on x86
PR port-arm/58100: /dev/ttyVI* missing on aarch64
PR port-arm/58101: /dev/nvme* missing on aarch64
PR port-arm/58102: /dev/raid* missing on aarch64
On Cygwin, the path '/././..././' is normalized before being passed to
the child 'make' process. Since overly long pathnames are not required
to be supported on all platforms, remove the test.
1. For tools that use elftoolchain: always use elftoolchain's
elfdefinitions.h. Don't even think about looking at the host's
sys/exec_elf.h, which makes no sense and should never happen.
(ELF tools that don't use elftoolchain, like m68k-elf2coff,
continue to use nbincludes/sys/exec_elf.h. But no more nbincludes
hacks in elftoolchain.)
2. For kernel components (solaris, zfs, dtrace): always use
sys/exec_elf.h, even in Solaris components via sys/elf.h.
elfdefinitions.h is not wired up in the kernel build at all.
3. For most userland components that involve libelf: use
elfdefinitions.h via libelf header files (libelf.h, gelf.h).
libdtrace in particular requires _all_ R_* reloc type definitions,
but sys/exec_elf.h brings in only the _current machine's_ R_*
reloc type definitions. (While here: Use uintptr_t instead of
Elf_Addr for pointer-to-integer cast, since Elf_Addr is MD and
provided only by sys/exec_elf.h, not by elfdefinitions.h.)
And most userland components using libelf don't rely on any
properties of the current machine from sys/exec_elf.h, so they can
use libelf's elfdefinition.h.
Exceptions:
- dtrace drti.c relies on link.h -> link_elf.h -> sys/exec_elf.h,
but it also relies on sys/dtrace.h -> sys/elf.h ->
elfdefinitions.h like other userland components using sys/elf.h.
- kdump-ioctl.c uses sys/exec_elf.h directly and sys/dtrace.h ->
sys/elf.h -> elfdefinitions like other userland components using
sys/elf.h.
- t_ptrace_wait.c (via t_ptrace_core_wait.h) uses libelf to parse
core files, but relies on sys/exec_elf.h for struct
netbsd_elfcore_procinfo.
None of these exceptions needs all R_* reloc type definitions, so
as a workaround, we can just suppress libelf's elfdefinitions.h by
defining _SYS_ELFDEFINITIONS_H_ and use sys/exec_elf.h in these
exceptions.
And undo the whole BUILTIN_ELF_HEADERS mistake. This was:
- half bogus workarounds for missing build_install dependencies in
tools/Makefile, which are no longer missing now, and
- half futile attempt to use src/sys/sys/exec_elf.h via nbincludes in
tools involving libelf instead of libelf's elfdefinitions.h, which
collides.
Longer-term, we may wish to unify sys/exec_elf.h and libelf's
elfdefinitions.h, so we don't have to play these games.
But at least now the games are limited to three .c files (one of
which is generated by Makefile.ioctl-c), rather than haphazardly
applied tree-wide by monstrous kludges in widely used .h files with
broken hackarounds to get the tools build lurching to completion.
of just writing the driver's map into the hardware ( which may have been
modified by the likes of wsfb )
With this we get a readable console even when exiting X in a less than
graceful manner.
"pciide-disable-dma" property on the on-board "aceride" to true. This
is intended to be a temporary measure until the issue that makes it not
work correctly is found and fixed.
ccdstrategy() -> ccdstart() -> ccdbuffer() from softint context.
Allocating the buffer with PR_WAITOK here is forbidden.
Change ccdstart() / ccdbuffer() to report failure back to caller and
pass PR_WAITOK / PR_NOWAIT as an additional argument.
Call ccdstart() with PR_NOPWAIT from ccdstrategy() and on error defer
to the kthread. Call ccdstart() with PR_WAITOK from kthread so requests
from kthread always succeed to allocate the buffers.
Remove the (non working) throttling on low memory as it is no longer needed.
Fixes PR kern/58043 "kernel crash in assert_sleepable() in -current,
dk(4) driver?"
copy, since we don't have m4 available. Use pax to install it because
using the Makefile needs more stuff available (nbsed) which we have not
built yet.
The C standards do not specify a fixed type for an array subscript, it
just has to be an integer type. Previously, query 4 fired for the
ubiquitous expression 'ptr[sz]' when sz had type 'size_t'.
The test platform_ilp32_long is unaffected by this change, as the
integer constant 0x80000000 has type 'unsigned int', while size_t is
'unsigned long' on those platforms, and even though the types 'unsigned
int' and 'unsigned long' have the same value space, there's still a
conversion, at least for now.
charlotte