segments up to 0x1fff bytes but even rounded to 32bit this seems to
confuse the rest of the audio code these days
TODO: we don't need to interrupt at every single segment
either way, with this mpg123 doesn't produce semi-random funny noises
anymore
_not_ get removed if the call goes to the rump namespace.
So, now it's possible to use e.g. tcpdump (and most other utilities
which hardcore a /dev pathname) on a rump kernel:
golem> setenv RUMPHIJACK blanket=/dev/bpf
golem> tcpdump -n -i virt0
tcpdump: WARNING: SIOCGIFADDR: virt0: Device not configured
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on virt0, link-type EN10MB (Ethernet), capture size 96 bytes
21:55:38.925596 IP 192.168.2.101 > 204.152.190.12: ICMP echo request, id 47811, seq 0, length 64
21:55:39.095596 IP 204.152.190.12 > 192.168.2.101: ICMP echo reply, id 47811, seq 0, length 64
(if you additionally set socket=all in RUMPHIJACK, tcpdump doesn't
whine about the "not configured" interface)
in particular, parse.y was being processed twice.. with one
process leaving a y.tab.h file behind
no need to explicitly add scan.c, parse.c and parse.h to CLEANFILES,
the framework knows they are generated and will remove them
slightly better in the multithreaded exec case in terms of partial
frames sent. Plus, it's theoretically a little cheaper.
There's still a gray area with partial transfer from sendmsg(),
but I'm not sure I care enough about some academic scenario to
start fixing it (it basically needs an OOB exec signaller).
the exec handshake to return.
In addition to being The Right Thing To Do, fixes some nasty
conditions for CLOEXEC fd's (or at least does so in theory, I
couldn't create any problems although I tried).
subdirectories.
Also, bsd.lib.mk requires a defined LIB, otherwise it will generate
unwanted commands during clean. It even failed on netbsd-4 where
'rm -f' needs at least one parameter which is missing due to recent
corrections in make/vars.c.
defined in terms of PROG, so later on we would end up with target duplicates
because both PROG_CXX and PROG were being converted to PROGS_CXX and PROGS.
Did not catch this earlier because the test build I did was not clean and
thus the duplicate targets did not have nasty effects.
ahoka