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

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Mon, Apr 07, 2025 at 23:58:13 -0700, Paul Goyette wrote:

> attachment.  Later, when the amdsmn module is loaded, it cannot
> attach in the device tree because the attachment point is already
> occupied by pchb. If you use drvctl to delete the pchb instance you
> can then load the module and amdsmn will attach correctly.
> 
> I propose that a new /etc/rc.d/drvctl script be provided (with a
> default of drvctl=NO in rc.conf) to automate the "eviction" of the
> pchb instance.  This script is structurally identical to the
> /et/rc.d/modules script - nothing fancy.  A copy of the new script
> is attached to this email.

I don't like this too much.  It's a nice (no sarcasm) quick kludge
that one can use locally to work around the current shortcomings of
autoconf and modload, but I don't think this is suitable as the
general solution.

Think of what you are really trying to express here.  Then look at
what one has to write to epxress that.  Then ask yourself, does that
writing clearly communicates the intent?  I posit that it doesn't
(though you didn't provide a complete example and force every reader
to do the legwork themselves), as the information pertinent to a
single device/module is split into two configuration files with this
approach.

The name drvctl.conf is also too generic, IMHO.  With a name like
that, does it apply to every invocation of drvctl?  Also, the hack of
just calling modload with args from the config file kinda works for
modload b/c it doesn't do much of enything else but loading the named
modules.  drvctl, OTOH, does many things, but I gather only the -d
makes practical sense here, or?  As I said, nice local kludge, not
very good generic solution suitable for public consumption, IMHO.


-uwe