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 <b...@bsd.de> > Message-ID: <20250409091610.ga28...@irregular-apocalypse.k.bsd.de> > > | 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
