lots of data, e.g. ~18k on a PCI system with few add-in devices; use
with MSGBUFSIZE=...). Useful to have here so that people who want as
much data about the PCI configuration in a machine can get it without
having to craft their own code. Also, clean up a few of the other
#if 0'd printfs.
* print all configuration space registers. Then, where possible,
interpret them. (That is, PRESENT ALL THE DATA, then interpret it --
don't hide data behind interpretation. Also, when interpreting
fields, try to print out the specific value that's being interpreted.)
* handle different header types.
* allow caller to specify a function which can interpret the
device-dependent header and is responsible for pretty-printing it.
It spews (use 'options MSGBUFSIZE=...' 8-), but when you want the data,
you really want _all_ of it.
Still needs some cleanup and additional code (e.g. interepretation
of PCI-PCI (type 1) and PCI-Cardbus (type 2(?)) bridge headers).
pci_mapreg_info() call. pci_mapreg_map() implies this check,
but code which calls pci_mapreg_info() has to check it explicitly.
Otherwise, if memory space is disabled, the driver does the wrong
thing, and tries to use memory space anyway, potentially resulting
incorrect driver operation and no useful error message.
* we already have the vnode interlock, so vref() should not ask for it again.
* we call VOP_RECLAIM/VOP_INACTIVE(), which shouldn't be duplicated in vrele().
The graphics device driver passes a "default attribute" for normal text
output to the wscons framework. If the emulation module needs more
attributes (for different "renditions") it can allocate them via a
callback.
For now, only the "sun" emulation makes use of it.
-initialize errno to 0 before receiving
-minimal allowed packet size is 4 (empty data packet)
-Be nice to the TFTP server - tell it that the transfer is finished
(additinal ACK at EOF, ERROR otherwise). Otherwise, it will linger
around and retransmit. This can be left out (TFTP_NOTERMINATE) if we
are really short on space.
fixes problem reported by Ken Nakata <kenn@synap.ne.jp> on the mac68k
where the stack amap chunking caused entry->end to wrap around to zero,
thus corrupting the map entry list and causing kmem_map to fill.