Revert "Define PNP info after defining driver modules"

This reverts commit aa37baf3d7cf51da92fd367476182802e71838ae.

The reverted commit was motivated by a problem observed on stable/12,
but it tur

Revert "Define PNP info after defining driver modules"

This reverts commit aa37baf3d7cf51da92fd367476182802e71838ae.

The reverted commit was motivated by a problem observed on stable/12,
but it turns out that a better solution was committed in r348309 but not
MFCed. So, revert this change since it is unnecessary and not really
correct: it assumes that the order in which module metadata records is
defined determines their order in the output linker set. While this
seems to hold in my testing, it is not guaranteed.

Reported by: cem
Discussed with: imp

(cherry picked from commit 519b64e27fddf10c0b7f6a615edbad730b8c6c45)

show more ...

Define PNP info after defining driver modules

PNP info definitions currently have an unfortunate requirement in that
they must follow the associated module definition in the module metadata
linker s

Define PNP info after defining driver modules

PNP info definitions currently have an unfortunate requirement in that
they must follow the associated module definition in the module metadata
linker set. Otherwise devmatch can segfault while processing the linker
hints file since kldxref maintains the order in the linker set.

A number of drivers violate this requirement. In some cases this can
cause devmatch(8) to segfault when processing the linker hints file.
Work around the problem for now simply by adjusting the drivers.

Reviewed by: imp
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D28260

show more ...