Re: Proposed new /etc/rc.d/drvctl script

[Christoph Badura <bad%bsd.de@localhost>]

On Wed, Apr 09, 2025 at 03:11:41AM -0700, Paul Goyette wrote:
> On Wed, 9 Apr 2025, Christoph Badura wrote:
> >Isn't this barking up the wrong tree?
> >First of all, WTF amdsmn4)?  Apparently there is no man page.
>
> AMD system management bus.  Talk to riastradh about the missing man
> page!  :)  amdsmn provides an attachment for amdzentemp(4) sensor.

So, not even something that's critical for the system to go multi-user.

> >Our autoconfiguration system handles this case just fine with match
> >priorities.
> >
> >That should work for modules too.  martin@ noted this in the PR.
> >
> >I recently came into a possession of an Infinite Noise TRNG that attaches
> >as a ucom(4) by default.  The to-be-written driver should attach it as a
> >rng device and use match priority to make that happen.  So this is a more
> >generic problem that needs solving in the module and autoconfiguration
> >framework.
> 
> Match priority doesn't work here..
> 
> Initially we have only one driver present, pchb.  The second, higher
> priority driver arrives later (when the module gets loaded) but by that
> time it is too late - pchb is already "claimiing" the attachment.  We
> need to "evict" pchb to make room for amdsmn.  But with our current
> autoconfig system the amdsmn_attach doesn't even get called.  We skip
> over the "occupied" attachments.

Yes, someone needs to make the autoconfiguration system to call amdsmn_match.
Obviously.  The machinery is there.  the xxx_match functions are supposed
to be idempotent.  The machinery to detach devices is there.  It's just
the SMOP for someone to stitch together the pieces.

BTW, I'm not trying to make you do that work.  As I mentioned I need that
functionality too and would be happy to do the work.

> >How do you plan to get rid of the script once we've fixed the underlying
> >issues.
> 
> IF we rewrite autoconf stuff to enable auto-eviction, we can simply
> obsolete this fiile.  Setting drvctl=NO in rc.conf is the default to
> disable the script.

No you can't simply obsolete this file.  Your intent was probably to
introduce it for this special purpose.  But you do not know what other
users will use it for.  And we have no way of polling them all.
Feature creap is easy to slip in but very difficult to evict once it got
its roots entangled into the system.

This isn't even necessary.  You can just as well add the necessary drvctl
commands to $start_precmd in /etc/rc.conf.d/modules.

I simply do not see the necessity to add the script for a non-critical
special case when we already have equivalent functionality to work around
the issue until the real cause is fixed.

--chris