you can have races when multiple processes try to unlink it. Check the link
count to see if we have won the race.
While here:
- use snprintf
- use warn
- use size_t/ssize_t
- use loops instead of goto
- KNF
The word 'write' now means to write to the file that holds the shell
commands to be run later.
The word 'print' is now used exclusively for handling the output of the
child commands and printing them to make's stdout.
No functional change.
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/config/rs6000/rs6000.c#rev1.13
This was removed accidentally when merging GCC10 into our tree.
Note that some firmwares, e.g., Explora, refuse to execute ELF
kernel image if this program header is present.
Now, GCC10 becomes just fine for all three powerpc sub-archs, i.e.,
oea, booke, and ibm4xx, as far as I can see. No regressions are
observed for ATF.
OK mrg
processors as POWER9 if -misel flag is specified.
rs6000_machine_from_flags() assumes ISEL instructions are supported only
for POWER9 and successors. However, ISEL is also implemented for 32-bit
booke processors.
Since our kernel for booke is compiled with -misel, this regression
completely breaks it.
As a fix, check whether CPU is 64-bit capable or not, before checking
-misel flag.
The problem has been reported as 100108 to upstream:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
OK mrg
The locks were held while callout_halt() and workqueue_wait()
without reason.
And the locks also were held at callout and workqueue handler
so that the handler kicked by those function couldn't acquire
the lock.
The reasons why those are unneccesary are:
- Items of callout_t are protected by callout_lock
- Items of struct workqueue and struct work are protected
by q_mutex in struct workqueue
- Items of struct sppp_work protected by atomic_cas(3)
- struct pppoe_softc does not free before workqueue_wait() and
callout_halt() even if the locks are not held
- include <bsd.init.mk> now that we can do it, because we need Makefile.rump
to be included first, so that NOLINT gets defined, so that we don't end up
building lint modules just for this.
inspire the GCC_NO_* series of variables, and explain some
about what the issues may be for each, hopefully providing some
direction on how to fix new warnings in this space.
christos asked me for this last year, and it's finally complete
enough to commit. :-)
so that when this code accesses mem_clustes[0] and mem_clusters[1]
it does't reach out of bounds.
XXX: should be in a header, but it's ugly to fix and i stopped
when bus_dma.c wouldn't build.
