This lets the compiler decide whether to actually inline the code (which
it does). It also provides better type safety and avoids a few
underscores and parentheses in the code.
This alias was only actually used in very few places, and changing it to
unsigned char or any other type would not be possible without generating
lots of compile-time errors. Therefore there was no abstraction, only
unnecessary complexity.
Somewhere in the refactorings of the last month, the parameter types of
the Arch functions had their constness fixed, therefore the UNCONST is
no longer necessary.
When it became disabled 9 years ago, there were 15 instances of UNCONST
in the code. These have been removed in the latest cleanup sessions.
Tested with GCC 5 from NetBSD 8 and GCC 10 from pkgsrc.
I'm unhappy with the (unsigned) casts for the enum constants, but there
is no way around that since the base type of enums is int by definition,
and there is no way in C90 to explicitly specify the base type of an
enum type.
The (size_t) casts on the pointer differences are another pain point,
but for these as well, C90 does not have a ready-made solution. A
possible workaround would be an inline function ptr_diff that returns
size_t instead of ptrdiff_t, but that would make the code look even more
bloated than with the casts.
The remaining casts to (char), (int) and (time_t) look so suspicious
that it's easy enough to stumble upon them, as soon as someone finds the
time to fix these properly by adding a function ParseInt or
ParseSeconds.
- Implement pmap_growkernel(), and update kernel pmap's stats with atomics.
- Then, pmap_kenter_pa() and pmap_kremove() no longer need to allocate
memory nor take pm_lock, because they only modify L3 PTEs.
- Then, pm_lock and pp_lock can be adaptive mutexes at IPL_NONE which are
cheaper than spin mutexes.
- Take the pmap's lock in pmap_extract() if not the kernel's pmap, otherwise
pmap_extract() might see inconsistent state.
all mine)
- Use tpidr_el1 to hold curlwp and not curcpu, because curlwp is accessed
much more often by MI code. It also makes curlwp preemption safe and
allows aarch64_curlwp() to be a const function (curcpu must be volatile).
- Make ASTs operate per-LWP rather than per-CPU, otherwise sometimes LWPs
can see spurious ASTs (which doesn't cause a problem, it just means some
time may be wasted).
- Use plain stores to set/clear ASTs. Make sure ASTs are always set on the
same CPU as the target LWP, and delivered via IPI if posted from a remote
CPU so that they are resolved quickly.
- Add some cache line padding to struct cpu_info, to match x86.
- Add a memory barrier in a couple of places where ci_curlwp is set. This
is needed whenever an LWP that is resuming on the CPU could hold an
adaptive mutex. The barrier needs to drain the CPU's store buffer, so
that the update to ci_curlwp becomes globally visible before the LWP can
resume and call mutex_exit(). By my reading of the ARM docs it looks like
the instruction I used will do the right thing, but I'm not 100% sure.
- Remove memory barriers from the atomic ops. I don't understand why those
are there. Is it some architectural thing, or for a CPU bug, or just
over-caution maybe? They're not needed for correctness.
- Have unlikely conditional branches go forwards to help the static branch
predictor.
This change fixes a bug that extra delay() is called only once even if
atomic_cas_uint() isn't failed or delay() isn't called when atomic_cas_uint()
failed.
The reason of this bug was that I simply converted FreeBSD' atomic_cmpset_int()
to atomic_cas_uint(). The return value's semantics is different.
else sys.mk will attempt to write it to the source tree,
which may be r/o and fail.
XXX may cause updates builds to fail because a file listed
in .depend won't exist anymore.
Just in case the given str is not really a string.
The POSIX 2018 documentation on strndup does not specify as clearly as
possible whether s has to be a string or whether raw memory is
acceptable as well. It only indirectly calls the s parameter of strndup
a string.
This avoids unnecessary string allocations, especially for long lists.
There is no unit test to cover this code. Since this is an obscure,
undocumented part of make, I wasn't able to come up with a unit test.
Therefore I resorted to write a separate testing program to verify the
expected results.
$ cat <<'EOF' >dir_test.c
#include <stdio.h>
#include "make.h"
#include "dir.h"
int main(int argc, char **argv)
{
int i;
Lst lst;
char *flags;
lst = Lst_Init(FALSE);
for (i = 1; i < argc; i++)
Dir_AddDir(lst, argv[i]);
flags = Dir_MakeFlags("-I", lst);
printf("%s\n", flags);
free(flags);
return 0;
}
EOF
# Needs some trivial patches to Makefile and main.c
$ make PROG=dir_test EXTRA_SRCS=dir_test.c EXTRA_CPPFLAGS=-DNO_MAIN \
COPTS.main.c=-Wno-unused-function NOMAN=1
$ ./dir_test a b c
$ mkdir a b c
$ ./dir_test a b c
-Ia -Ib -Ic
$ rmdir a b c
Catch up with previous to unbreak autoloading of verbose modules.
PR kern/55535
CVS: ----------------------------------------------------------------------
CVS: CVSROOT cvs.NetBSD.org:/cvsroot
CVS: please use "PR category/123" to have the commitmsg appended to PR 123
CVS:
CVS: Please evaluate your changes and consider the following.
CVS: Abort checkin if you answer no.
CVS: => For all changes:
CVS: Do the changed files compile?
CVS: Has the change been tested?
CVS: => If you are not completely familiar with the changed components:
CVS: Has the change been posted for review?
CVS: Have you allowed enough time for feedback?
CVS: => If the change is major:
CVS: => If the change adds files to, or removes files from $DESTDIR:
CVS: => If you are changing a library or kernel interface:
CVS: Have you successfully run "./build.sh release"?
