Two new ioctls are added to the wsdisplay device, named WSDISPLAY_GMSGATTRS
and WSDISPLAY_SMSGATTRS, used to retrieve the actual values and set them,
respectively (the name, if you are wondering, comes from "message attributes").
A new emulop is added to the underlying display driver (only vga, for now)
which sets the new attribute for the whole screen, without having to clear
it. This is optional, which means that this also works with other drivers
that don't have this new operation.
Five new kernel options have been added, although only documented in
i386 kernels (for now):
- WSDISPLAY_CUSTOM_OUTPUT, which enables the ioctls described above to
change the colors dynamically from userland. This is enabled by default
in the GENERIC kernel (as well as others) but disabled on all INSTALL*
kernels (as this feature is useless there).
- WS_DEFAULT_COLATTR, WS_DEFAULT_MONOATTR, WS_DEFAULT_BG and WS_DEFAULT_FG,
which specify the default colors for the console at boot time. These have
the same meaning as the (already existing) WS_KERNEL_* variables.
wsconsctl is modified to add msg.default.{attrs,bg,fg} and
msg.kernel.{attrs,bg,fg} to the display part, so that colors can be changed
after boot.
Tested on NetBSD/i386 with vga (and vga in mono mode), and on NetBSD/mac68k.
No objections in tech-kern@.
gets built and installed in a hp700 distribution.
TODO
- merge with hp300
- pick a preferred method for dealing with the elf headers.
hp700-mkboot and prep-mkbootimage (bintuils) vs mips-elf2ecoff and
tools/installboot
Responses. Ad hoc mode uses these entries to track network peers.
This provides passive-scan information for the current channel in
infrastructure mode (XXX really should keep it in a different
table). Host APs will someday use these entries to track APs in
the same ESS for AP-to-AP bridging.
long, not an int, and this causes "problems" on LP64be machines
(sparc64, etc). Assign the value to a temporary int and instrument
that instead. Should be fine until someone wants a message buffer
larger than two gigabytes.
Bump the default values for these to the values used by FreeBSD,
and also adjust ti_init_rx_ring_jumbo() to use the same constant
that FreeBSD uses. Yes, this consumes more kernel memory.
The effect of this is that you can use jumbo frames in a back-to-back
setup with TCP windows up to about 250KB and get ~930Mbit/s throughput,
while we were earlier limited to around 3-400Mbit/s, and trying to push
above that mark by widening the TCP window caused
ti0: jumbo buffer allocation failed
messages to be logged and a corresponding stall in the traffic.
NatSemi) Geode SC1100 controller (as found on the Soekris
NET4801). The chip has two bugs: the first requires dword
alignment, and the second cannot handle exact 64K transfers.
Also, fix a few typos while we're here.
Timings from FreeBSD. Reviewed by Manuel Bouyer.
must use a full node for received management frames, or we are unable to
complete association and talk to the client. I could add an
"if mode == HOSTAP" to fix this, but instead I am reverting the change and
remanding it to the person who broke it.
IBSS nodes. Do not send an EXPIRE-type DEAUTH message when IBSS
nodes time-out. This ends the panic that rev 1.25 fixed, but
without a dual-use ieee80211_node_leave.
will eventually share it.
In the IBSS merge logic, check conditions in a different order so
that they run faster in the common case---no merge. Fix the
rate-limiting on the debug outputs (enabled by IFF_LINK0).
