newbus: Create %probe_bias in every devclass

[imp]

Summary

Add a user-configurable %probe_bias in every devclass. This value is
added to the return value of probe routines for that devclass. This can
be used to break ties and/or change which driver attaches from the
default, should that drive be ill-suited to some user's needs.

The new tunable / sysctl dev.foo.%probe_bias sets devclass foo's
probe_bias. To make a device driver more favored, this should be a
positive value. To make it lass favored, this should be a negative
value. It does not affect devices for which a probe routine returns
zero, nor will it allow one to force a device to attach that otherwise
returns an error for its probe.

Sponsored by: Netflix

[jrtc27]

sys/kern/subr_bus.c

1724

Do we need to cap this at 0 (or handle > 0 in line 1734)?

[imp]

sys/kern/subr_bus.c

1677

"above here" in comment below.

1724

No. I don't think so. I originally did cap it based on logic higher in this loop...
But it does point out the need for another change...

1729–1730

this whole block is redunant; we already checked == 0 where I flagged it as "above here" so I should delete this code since it is dead.

[imp]

but I'll do that fix as another commit

[jrtc27]

sys/kern/subr_bus.c

1724

Well what happens if result is -1 and I bias it by 2? Should that not be the same as 0?

1729–1730

That was the inner loop; this is to make that case also break out of the outer loop.

[imp]

rebase

[imp]

sys/kern/subr_bus.c

1724

no. It shouldn't. I've reworked the subsequent code so it no longer matters.

return == 0 is a special case due to really old drivers that did that and expected softc to live between probe and attach. I don't think we've killed all of those in the tree yet.

1729–1730

correct... I've updated the prior patch to fix this issue.

[jhb]

I think it would be useful to include a specific example in the commit log (and I wish there was a manpage to document this in, but I can't think of a good one).

I would suggest iwlwifi vs iwm except that LinuxKPI drivers don't probe normally (they all run in a late SYSINIT for some reason) so this won't work for that case. :(

sys/kern/subr_bus.c

1680–1681

[imp]

In D44264#1011411, @jhb wrote:

I think it would be useful to include a specific example in the commit log (and I wish there was a manpage to document this in, but I can't think of a good one).

We likely need to create one.

I would suggest iwlwifi vs iwm except that LinuxKPI drivers don't probe normally (they all run in a late SYSINIT for some reason) so this won't work for that case. :(

We need to fix that. It's unacceptable. I'm tired of all the stupid hacks in LinuxKPI because the original author couldn't be bothered to do things correctly... See also the restriction on not being able to be loaded from the boot loader...

[imp]

I would suggest iwlwifi vs iwm except that LinuxKPI drivers don't probe normally (they all run in a late SYSINIT for some reason) so this won't work for that case. :(

We need to fix that. It's unacceptable. I'm tired of all the stupid hacks in LinuxKPI because the original author couldn't be bothered to do things correctly... See also the restriction on not being able to be loaded from the boot loader...

But more fundamentally, that means we can never have a LKPI driver bid against a "native" driver unless both are loaded as modules.... Assuming that late sysinit is where they run...