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

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

On Wed, Apr 09, 2025 at 09:32:02PM +0700, Robert Elz wrote:
>     Date:        Wed, 9 Apr 2025 11:16:10 +0200
>     From:        Christoph Badura <bad%bsd.de@localhost>
>     Message-ID:  <20250409091610.GA28900%irregular-apocalypse.k.bsd.de@localhost>
> 
>   | How do you plan to get rid of the script once we've fixed the underlying
>   | issues.
> 
> I doubt there would be any need for that -- it is off by default (or should
> be once committed) and even if enabled, does nothing unless the config file
> exists and contains some work for the script to do.

But that's beside the point, isn't it.  It hinges all on that we do not
know how ends up using it.  If this script would solve a more general
problem I wouldn't object as stringly.  But this seemed like a very quick
hack for a very specific problem that was easy to solve with existing
machinery.

>   | Your proposed script pampers of the symptoms in a crude way.
> 
> Paul's usage of it might in fact be just that, but in general I suspect
> it might be a good idea to be able to run drvctl early in the boot sequence
> (perhaps using -S to suspend some locally toublesome device) as a generally
> available facility.
> 
> I don't see what harm it can possibly do to anyone.

The harm done by adding special functionality for every edge case that
someone comes up with is that you'd end up with a haystack of special case
functionality and options but never solve the more general problems
because you've never stopped to think about them.  And then you end up
with something like the systemd "ecosystem" with hundred upon hundreds of
special case configuration directives.

Likewise, it's not a good idea to solve problems that one suspects might
manifest.  It's better to solve real problems that demonstrably exist.  But
it is important to stop to think if there is a more general problem that
needs solving hiding behind the special case at hand.

Its the mark of a good design that it can solve problems that the
designers couldn't think of when they created the design.

> It is also true that some UPSs with USB interfaces for control attach as uhid,
> rather than as ugen which the applications generally want, I haven't looked at
> how yet, but this mechanism might be able to handle that as well - previously
> I have "papered over" that by specifically configuring a specific USB port as
> ugen in the kernel config file, but that is very crude, and doesn't work at
> all if the USB port the UPS gets connected to varies over time (after all, it
> is all USB, any speed compat socket should work...)

I'm under the impression that the consenus is that we should make ugen
usable for all devices, i.e. attach both and ugen and a device driver
instances to all usb devices.

That could also help plunky's Intel bluetooth driver discussed in February
on tech-kern.

If autoconfiguration could match on vendor and product it you express this
better in the config file.

Perhaps
  no uhidev* at uhub? port ? configuration ? interface ? vendor foo product bar

And you could use that in userconf lines in boot.cfg.

--chris