and 795x. This was present in the driver before, but disabled due to
problems with the actual randomness of generated numbers on the
ubiquitious 7900-series parts. The code here is far, far more
conservative than anyone else's driver for this RNG is -- but I
believe that conservatism is called for, because the 79xx RNG
design is missing a number of pieces from Hifn's "reference" 6500
RNG, and thus the numbers it generates must be treated with some
care.
Support for the 7811 RNG (which is a full-fledged 6500 type
generator) is pretty much the same here as in other variants of
this driver, except that it uses Hifn's "worst case" estimate of
actual entropy per output bit, so it will accumulate bits much
more slowly. The 7811 support is untested.
on (e.g. cardbus), write the wep keys to the card. Fixes problem of
receiving gibberish if one has set wep keys before bringing the
interface up, and also after ifconfig ath0 down; ifconfig ath0 up.
(Tested with current from 20050926 with local mods, and discussed with
sam@ and dyoung@. This is not 100% right, but significantly better
than before. Really we should have an interator in net80211 to repush
all key state, include per-node keys.)
ptyfs_write() rather than setting a flag and updating these times
through ptyfs_itimes() at some indeterminate time in the future.
However, just use the "time" variable to set the times instead of
using a potentially expensive call to nanotime(). A HZ resolution
on these timestamps is more than enough.
(Possibly incomplete) fix for PR kern/31430.
OK'd be christos@.
xennetback instances. To support this, more fields from xni_page to xni_pkt.
This would also have the effect to move more code into the
while (!SLIST_EMPTY(&pkt_page->xni_pkt_head)) loop in xennetback_tx_free().
By passing xni_pkt instead of xni_page to xennetback_tx_free we can
avoid the loop, and the xni_pkt_head list completely. There is even a sligh
performance increase if the domU deals with xni_txring->event properly.
Based on comments from YAMAMOTO Takashi.
Framebuffer drivers use their own minor device number to find their device entry
in fbdriver methods ( like cgsix uses cgsix_cd[minor] ) but fb passed the fb
device's unit number which works only as long as all registered fb devices use
the same underlying driver. With different fb drivers, like a cgsix and an ffb, both will be (native) unit number 0 so with the old code /dev/fb1 would be
unusable.
tls