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
