matter what $0 is (or is not) set to. This means that editrc(5)
lines that start "sh:" are used (in addition to those with no prefix,
which will usually be most of them), regardless of the name or manner in
which we were invoked.
OK christos@
It seems that alarm(1) is not enough time for the thread to actually exit after quittingtime = 1.
It randomly failed with "Test program received signal 14" on a slow environment.
getenv()/setenv()/unsetenv() which manipulate the envornoment
the shell was passed at entry.
These are a little odd in sh as that environment is copied into
the shell's internal variable data struct at shell startup, and
normally never accessed after that - in builtin commands (test.
printf, ...) getenv() is #defined to become an internal sh lookup
function instead, so even those never use the startup environment).
NFCI
- The DBM bit of the PTE is now used to determine if it is writable, and
the AF bit is treated entirely as a reference bit. A valid PTE is always
treated as readable. There can be no valid PTE that is not readable.
- LX_BLKPAG_OS_{READ,WRITE} are used only for debugging purposes,
and has been superseded by LX_BLKPAG_AF and LX_BLKPAG_DBM.
- Improve comment
The need for reference/modify emulation has been eliminated,
and access/permission faults have been reduced, however,
there has been little change in overall performance.
Breaks deadlock:
- usbnet_detach holds usbnet lock, awaits kpause in ure_reset
- callout holds softclock `lock' (sequential softints, blocks kpause
wakeup), awaits softnet_lock in tcp_timer_keep, frag6_fasttimo, &c.
- soclose holds softnet_lock, awaits usbnet lock in SIOCDELMULTI
This change breaks the deadlock by not passing the SIOCADDMULTI or
SIOCDELMULTI ioctl synchronously to the driver, which typically takes
the usbnet lock.
With this change, the ethernet layer still maintains the list of
multicast addresses synchronously, but we defer the driver logic that
updates the hardware multicast filter to an asynchronous USB task
without softnet_lock held.
This doesn't cause exactly the same ioctl to be sent to the driver --
usbnet just sends SIOCDELMULTI with an all-zero struct ifreq, and
might drop some ioctls if issued in quick succession. This is OK
because none of the drivers actually distinguish between SIOCADDMULTI
and SIOCDELMULTI, or examine the argument; the drivers just commit
whatever multicast addresses are listed in the ethercom.
Other than the different ioctl submitted, there is no change to the
ABI or locking scheme of usbnet, so this is safe to pull up to
netbsd-9. This means we unfortunately can't guarantee that if a
process issues SIOCADDMULTI and then sendto, the multicast filter
update will be done by the time of the sendto -- and, more
importantly, the packets received in reply to it. But failing to
guarantee that is better than deadlocking! Later changes on HEAD
will restore the synchronous multicast filter updates with much more
extensive ABI changes and API simplifications in usbnet(9).
Proposed on tech-net:
https://mail-index.netbsd.org/tech-net/2021/12/30/msg008164.html
XXX pullup-9
Use the same asynchronous task resetting a stalled/halted endpoint
and stopping a running endpoint -- either way we need to put the
endpoint back into a known state and, if there are transfers waiting
to run, start them up again.
- xhci_abortx must not drop the pipe (bus) lock -- usbdi(9) requires
this. So arrange to stop the endpoint and empty the queue
asynchronously.
- If the xhci softint claims an xfer for completion with
usbd_xfer_trycomplete, it must call usb_transfer_complete without
ever releasing the pipe (bus) lock -- it can't claim the xfer and
then defer the usb_transfer_complete to a task. So arrange to
reset the endpoint asynchronously, hold up new transfers until the
endpoint has been reset, and then do usb_transfer_complete
immediately.
This is really only helpful for debugging the software logic to
handle the trees of devices for suspend/resume, not for debugging the
drivers, which is most of what we need to do. If anyone still finds
this useful they can make a sysctl knob for it or something, but for
now this substantially reduces the amount of debug output that's
getting in my way.
Since main.c 1.373 from 2020-10-18, make does not use iovec anymore, so
remove that test variant.
Document the details of why generating the test coverage took so long on
NetBSD < 10.
Add another test variant with optimization for binary size (-Os), since
with that option, GCC 10 does not perform the same data flow analysis as
with -O2, in particular it gets confused about whether local variables
are correctly initialized across function calls.
Print the approximate location based on the last command that has been
defined for the target. It would be possible to get more detailed
location information by counting the number of commands of the target,
but that would get messy due to .USEBEFORE, .USE and .DEFAULT, and
still, this is an edge case, so don't waste too much code for it now.
Having this hint about the location is more helpful than just a plain
"Variable X is recursive" without any further details.
The only fatal error that occurs while the makefiles are read in is the
one about recursive variables, which didn't give any hint about the
location before.
If a recursive variable is detected while evaluating the commands of a
target to be made, there is no location information, as before.
Reusing the target var-scope-local.o for several tests made the test
more difficult to understand than necessary. The test names '2' and '3'
didn't convey any meaning.
Instead, add more test targets that are named after what they test. Add
tests for each of the 5 variable assignment operators, to demonstrate an
inconsistency between '+=' and '?='.
Add tests for the built-in target-local variables as well and explain
the general concepts, in particular the exact point where target-local
expressions are expanded.
The lines in the expected output file are not generated in the same
order as they appear in the makefile, so allow the 'expect' lines in
non-linear order, in check-expect.lua.
kre