do drain' in many places, whereas fo_drain() was called in order to force
blocking read()/write() etc calls to return to userspace so that a close()
call from a different thread can complete.
In the sockets code comment out the broken code in the inner function,
it was being called from compat code.
BaiYang per PR lib/42434
the sad truth is that this doesn't help much because SIGEV_THREAD just
doesn't work (at least on -current, likely on -5, perhaps it worked
woth scheduler activations)
list of sources. This, in a rather curious twist of linker magic,
broke anything using rump file systems when librumpvfs was compiled
with LIBDPLIBS pointing to librump.
Thanks to the several people who reported the problem, and especially
Arnaud Ysmal for noticing the paramount symptom that components
compiled in src/lib did not work while ones compiled in sys/rump/librump
did work.
They were incorrect since 1997 on amiga and atari, and since 2002
on other ports, but fortunately they don't look so fatal.
Anyway, these values will be moved into <m68k/pmap_motorola.h> soon
since they are quite pmap implementation dependent.
patch OSIOC{G,S}IFFLAGS is supposed to work, but unfortunately getifaddrs
seems to be the next problem getting the 4.99.x i386 ifconfig working on an
amd64 current machine.
to ${LD} via:
${LDADD.${PROG}}
${LDFLAGS.${PROG}}
${LDSTATIC.${PROG}}
${LDADD.${LIB}}
${LDFLAGS.${LIB}}
OTOH you can't pass parameters to ${CC}, because in suffix rules make(1) only
knows the name of ${.IMPSRC} and ${.TARGET}; it's users' responsivility to
define ${CC} parameters to all the sources of a given ${PROG} / ${LIB}.
Should address bin/42381.
(Bug in this commit log was pointed out by mrg@.)
dump.c includes misc.h but misc.h is generated on-the-fly.
Note that dump.c is out of the makeerrnos.sh -> misc.[ch] generation rule
now. This prevents ktruss from being unnecessarily rebuilt in rescue/.
Pointed out by enami@, thanks!
context. This fixes a long-standing but seldomly seen deadlock,
where the kernel was holding pages busy (due to e.g. readahead
request) while waiting for the server to respond, and the server
made a callback into the kernel asking to invalidate those pages.
... or, well, theoretically fixes, since I didn't have any reliable
way of repeating the deadlock and I think I saw it only twice.
