don't expect/provide pci_decompose_tag to be a MI, public function. It
wasn't intended to be to begin with, and uses of it (e.g. the one in the
'de' driver) are quite likely to be incorrect.
packets. It's not clear whether latency will be affected much. It could be.
However, for the time being, getting full rates out of HIPPI or SCSI are what
interests us at NASA, so we'll hew to this bias.
the PCIA revision, and whether or not the STD I/O EISA bridge is
present. Decode, but don't bother displaying, the power consumption
information for each PCI slot.
compliation without DEBUG and/or DIAGNOSTIC happens without errors.
Note that all such initializations in the Alpha port are marked with "XXX
gcc -Wuninitialized". As far as I'm concerned, the one or two times
-Wuninitialized has saved me from problems are worth the (very minor) cost
involved with the initializations, esp. if it's noted why the
initializations are done. This was prompted by PR#3690, from Ted Lemon.
(1) object code can be shared (where the hardware makes that possible), and
(2) so that the file names better describe the systems which use them. (the
pci_swiz* files are for machines whose PCI interfaces require address
"swizzling." Later, there will be probably be other sets, e.g. pci_bwx*
for machines whose chipsets can easily deal with the Alpha BWX extensions
when doing device accesses.)
arguments, so that a device can tell if its memory and I/O spaces are
enabled. The flags are cleared, depending on the contents of devices CSR
registers, in the machine-independent PCI bus code.
This can be disabled (to save a bit of space) with the NO_KERNEL_RCSIDS
options, which is present but commented out in the ALPHA config file.
In ELF-format kernels, these strings are present in the kernel binary but
are not loaded into memory. (In ECOFF-format kernels, there's no easy way
to keep them from being loaded, so they _are_ loaded into memory.)
thorpej