that causes in updating.
Submitted by: Robert Watson
[[ NB: marko and I are trying an experiment: he'll try to fix typos
quickly in UPDATING, while I concentrate on content. ]]
on Alpha, primarily in the storage adapter area. Things like
Soundblaster-attached CDs, WD7000 etc for example. Try to get RELNOTES
for alpha to reflect reality a bit more.
* rewrite catopen() to remove duplicate code chunks and optimize
* if empty string is passed to catopen() as name argument then
catopen() will set errno to ENOENT (File not found), not EINVAL
* move search code to LOOKUP() macro to shrink amount of duplicated code
* move common resource freeing actions to __nls_free_resources() function
* exclude from build code related to MCLoadAll defintion since it is not
using at all
* style(9) related whitespace changes
Reviewed by: ache
in my tree for a long time. bde reviewed this once upon a time and
said it was OK, iirc. This also obviates the need to put ? in the
optstring argument to preclude the extra warning message which some
people think confuses users. When I made my getopt cleanups of a long
time ago, this was the compromise reached. I just neglected to commit
it until now.
PR kern/20895:
- Add FE_DAC new feature flag to distinguish between
64 bit PCI addressing (DAC cycles) and 64 bit PCI
interface (64 bit Memory BARs).
- Properly deal with chips that have a 32 bit PCI
interface but support and may generate DAC.
(Only SYM53C895A for now).
PR misc/17584 (at least partially addressed):
- Try detecting hardware combinations that trigger
spurious PCI master parity error detections by the
PCI chip. This work-around is implemented in the
`snooptest' routine and consists in retrying with
PCI master parity checking disabled if such an
error is reported by the PCI chip during this test.
Other:
- Fix a tiny bug in WIDE negotiation that was very
unlikely to be triggerred. The BUS width was wrongly
compared against chip's max. offset.
In the nexus case, there are no ivars for children of nexus devices,
and we were passing data in from before the device existed, hence ivars
are convenient as the softc doesn't really exist yet.
However, for pci->pci bridges, the pcib occupies a pci device itself,
which *does* already have ivars. However, softc is available and stable
at this point since we've been identified and are locating the bus during
attach. So, use softc for this version of pcib devices for storing the
physical bus number in.
