On May 11, 2021, at 22:53, Theo de Raadt <dera...@openbsd.org> wrote: > This is because the design of hotplug is completely broken.
Thank you, Theo, for the comprehensive reply. This was just the sort of feedback I’d hoped to get. Ok so we have established this is a terrible idea because of the way hotplug works. :) Let’s say someone was interested in solving* this. And let’s assume there was some infrastructure that you signify attach, detach of devices along with basic state (ready, not ready). (* - where solved is some value of “better than what’s there now”) […snip…] > Unfortunately there is no instrumentation in drivers or subsystems to > capture "ready to do work", and create the events at that point instead. > hotplug is hooked into subr_autoconf.c, this code is for handling the > device heirarchy, but it is not involved in operation, and thus unaware > of "readiness". Fixing this would require a subsystem by subsystem study, > figuring out where the glue should exist, and creating the events at > the CORRECT time. Would it make more sense to have a general solution which aggregates all the information from every device? (Maybe something like /dev/devstate, I dunno, names are hard). I could see that maybe this could be a side channel, though, if it’s somehow useful to know the state of a certain device (though no more so than /dev/hotplug already is admittedly). You’d also be getting a firehose of everything even though you might be only interested in disk devices, for example. Or, have something per subsystem? (Infrastructure could be shared, i guess). So for scsi, you might have something like “/dev/scsistate” which provides information to userland stuff on everything that’s under the scsi umbrella. This feels more friendly in that you would unveil only a particular subsystems monitor device, limiting the firehose and also the potential side channel. You might also want to attach more specific information to the message (for scsi, maybe attach LUN and target info in addition to the device name and type). But you pay for that in extra queues, devices etc. Any thoughts? I would be willing to try and develop something, it’s interesting to me and it will hopefully solve my iSCSI mount issues once and for all. :)
