802.11 drivers will use ieee80211_find_rxnode to match each received
packet with the ieee80211_node belonging to the sender. The driver
will use the ieee80211_node to track the sender's RSSI and other
statistics for, e.g., rate adaptation.
ieee80211_find_rxnode "fakes-up" missing ieee80211_nodes in IBSS
mode and in ad-hoc demo mode when it is appropriate. See the comments
in the source.
Also add ieee80211_find_txnode, which looks up the ieee80211_node
belonging to a MAC destination. ieee80211_find_txnode will also
fake-up missing nodes in IBSS/ad-hoc demo mode.
In ieee80211_encap, use ieee80211_find_txnode. This fixes the bug
in ad hoc packet-transmission reported by Greg Troxel, Urban Boquist,
and Kurt Schreiner.
in case the previous loop scheduled some more work to do (e.g. reset)
- use queue_freese to block the queue when a reset is pending too
- Avoid using WDCF_TH_RUN in some place that can be called from callout.
If the kernel thread is tsleep()ing somewhere, we may come here with
WDCF_TH_RUN set while being in the callout context. Fix a panic() in
tsleep() reported by Chuck Silvers.
- Use AT_WAIT instead of WDCF_TH_RUN wdcwait(), as we may not be in the
channel's thread context but still be able to tsleep(). Fix queue_freese
panics for WDC_CAPABILITY_NOIRQ controllers (port-mac68k/23208 by
Frederick Bruck).
So the problem is thus:
* The {u,}mulsidi3 generate two parallel sets which modify the upper and lower
halves of the target register.
* life_analysis() does not track subregister modifications -- if you don't
modify the whole register with a single set, it considers the register
unused.
The simple, if klugy, solution to this is to stick an explicit clobber in. It
seems to work.
While doing this, I noticed that constant folding was not happening for
32x32->64 multiplies. This is because the parallel set generated by
{u,}mulsidi3 cannot be folded at all. To solve this, I first expand to a
normal multiply, and then use a define_insn_and_split to convert it to the
parallel set after CSE and constant folding.
This patch has also been submitted to GCC bugzilla, but who knows if I'll get
a reply to that.
regular threads can block in the kernel while holding (libpthread) locks
and have to be continued
XXX if the blocked upcall is preempted, the blocked threads syscall
XXX return value can get lost
There's no reasonable situation where there will be one there, except if the
disk had data on it previously for some reason. It's significantly more
likely (read "the world until UFS2 was merged") that sector 0(..15)
contains really important stuff like boot blocks and disk labels.
Once again, I ask, why wasn't UFS2 implemented as a separate file
system a la lfs & ext2fs ?
It could have shared a chunk of the kernel code (just like those),
and had different userland tools and a different fs_type.
mycroft