http://mail-index.netbsd.org/source-changes/2020/04/16/msg116278.html
The reasoning turned out to be wrong; __KERNEL_RCSID() in header files
does *not* overwrite RCSID in main source files. The real problem is that
it inserts its RCSID into *every* object files. However, it can be still
useful even if heavily duplicated.
and everything gets more than 10 times slower by __HAVE_UNLOCKED_PMAP.
Note that we support three supervisor-level architectures for powerpc:
oea, booke, and 4xx. We have three different implementations of pmap as
a result. Whereas oea and booke support multiprocessor, 4xx does not.
overwriting RCSID in main source files.
XXX
The first argument of __KERNEL_RCSID() is neglected for ELF. If we wish
to have RCSID of header files in kernel binary, we need something like
__FBSDID() macro in FreeBSD.
there is some overhead for backend without persistent mappings
(backend needs to map the extra indirect segment page), but this
makes it possible to queue more I/O if using 64KB block size
tested on NetBSD/amd64 DomU against Linux/amd64 Dom0
compatible with Linux/i386 - they changed padding so that there is no
structure layout difference between i386 and amd64; there is no change
for amd64 due to implicit padding
since Linux seems to be the only xen blkback implementation supporting
indirect segments, follow that rather than public xen includes; note
their blkif_x86_32_request_indirect handling expect this layout,
particularly padding for i386 before indirect_grefs[]
in a consistent state. This most importantly avoids races between dlopen
and friends and fork, potentially resulting in dead locks in the child
when it itself tries to acquire locks.
than an internal field, so this works when the original buf is
wrapped by another one by e.g. dk(4)
fixes misfired assert when doing newfs on a wedge, reported by Manuel Bouyer
- Rename ci_cpuid_level to ci_max_cpuid and ci_cpuid_extlevel to
ci_max_ext_cpuid to match x86/include/cpu.h though cpuctl/arch/i386.c added
them first.
- Sort some entries.
- Add comment.
to the pool layer. It is taken out of POOL_QUARANTINE.
Advertise POOL_NOCACHE for kMSan rather than POOL_QUARANTINE. With kMSan
we are only interested in the no-caching effect, not the quarantine. This
reduces memory pressure on kMSan kernels.
The OSSv4 spec says we shouldn't really error if an invalid format is
chosen by an application. Things are especially likely to be confused
if we return MULAW, since in OSSv4 terms that means that's the native
hardware format. Instead, set and return the current hardware format
if an invalid format is chosen.
For the 24-bit sample formats, note that the NetBSD kernel currently
can't handle them in its default configuration, and will return an error
code if you attempt to use them. So, if an applicaton requests 24-bit PCM,
promote it to 32-bit PCM. According to the spec, this is valid and
applications should be checking the return value anyway.
In the Linux compat layer, we just use S16LE as a fallback. The OSSv3
headers that are still being shipped with Linux don't contain definitions
for fancier formats and we can reasonably expect all applications to
support S16LE.
From the perspective of reading the OSSv4 specification, NetBSD's
behaviour when an invalid sample rate is set makes no sense at all:
AUDIO_SETINFO simply returns an error code, and then we immediately
fall through to getting the sample rate, which is still set to the
legacy default of 8000 Hz.
Instead, what OSS applications generally expect is that they will be
able to receive the actual hardware sample rate. This is very, very
unlikely to be 8000 Hz on a modern machine.
No functional change when setting a sample rate between the supported
rates of 1000 and 192000 Hz. When a rate outside this range is requested,
the hardware rate is returned (on modern hardware, generally always 48000
Hz or a multiple of 48000 Hz).
for this, so that it does not require MAXPHYS override in kernel config
any more
this is useful even if we get indirect segment support one day,
for compatibility with Dom0's not supporting it, like currently NetBSD
