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. > > 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. > > 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. Alan Stern -- 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/
