Ashton Fagg <[email protected]> wrote: > On May 11, 2021, at 22:53, Theo de Raadt <[email protected]> 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. :)
We don't need a new subsystem. We just the operation changed, so it sends the event when the device is ready, rather than before it is ready.
