where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.
layer. Can improve write performance on SAS adapters under certain conditions
when the logical drive does not have write caching enabled. Also need to
reserver a couple of slots for commands for the driver to use - stops the
adapter shortage messages. Multiple commands can now cause QUEUE_FULL events,
so add that to the events handled, currently just ignoring it. Changes
based on the thread http://mail-index.netbsd.org/tech-kern/2011/02/08/msg009946.html.
cvs: ----------------------------------------------------------------------
used by drivers: a short name for the quiet/naive case and a string
to override the "pcidevs" based name by one provided by the driver,
ride on yesterday's kernel minor version bump
- now capable of auto-negotiation, use this as default media selection.
- add multicast filter support.
- code cleanup.
Code update from Paul Fleischer.
simplifying uvm_map handling (no special kernel entries anymore no relocking)
make malloc(9) a thin wrapper around kmem(9)
(with private interface for interrupt safety reasons)
releng@ acknowledged
by purpose) - this is a stack hog, and with this change my uTCA amd64
system boots again
a lot of similar code can be eliminated from pci device drivers this way,
but before doing so (and making the new function part of the module API)
I'd like to consider a modification to make it work with drivers which
prefer to print names from other sources (like pciide)
render glyphs scanline by scanline into a 64bit-aligned buffer, then memcpy()
it into video memory instead of writing directly.
This gives >10% speedup even on valkyriefb, likely more on PCIe framebuffers.
Glyphs which use the default attribute will be saved into offscreen video
memory the first time they're used and subsequent uses will just copy them
from there instead of rendering them every time.
This should give a nice speedup especially on slow CPUs.