On Thursday, October 29, 2015 10:31:08 AM Alan Stern wrote: > Good grief, don't you guys ever trim unwanted material from your > emails? I had to erase more than 4 screens worth of useless stuff > before getting to the relevant portions. > > On Thu, 29 Oct 2015, Tomeu Vizoso wrote: > > > >> Also, have you considered that not only drivers request resources? For > > >> example, the on-demand probing series would probe a device that is > > >> needed by an initcall, simplifying synchronization. > > Did Rafael ever say that only drivers could create these functional > dependencies? I don't recall seeing that anywhere. Presumably any > part of the kernel will be allowed to do it.
Right. > > > You really need to explain what you mean here or maybe give an example. > > > > There are initcalls that assume that a given resource is available. > > Because of async probes, or because the resource's driver being built > > as a module, or because the resource's driver gained a dependency > > (direct or not), those initcalls break unexpectedly at times. Well, I'm still unsure what initcalls are in question here. > > If resource getters could probe dependencies on-demand, those > > initcalls would be more robust to changes in other parts of the > > codebase. > > > > AFAIUI, your proposal would help with a device's dependencies being > > there when it's probed, but initcalls could still run into unfulfilled > > dependencies. > > One possible approach is to have a "wait_for_driver" flag, along with a > timeout value (or perhaps using a fixed timeout value). When a > dependency gets registered with this flag set, the function call > wouldn't return until the target device is bound to a driver or the > timeout has elapsed. > > This would make it easy to insert dependencies at probe time without > relying on deferred probing. I'm not sure about this to be honest. It seems like implementing it might be sort of tricky. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/