Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Lars-Peter Clausen <lars@metafoo.de>]

On 07/29/2016 09:45 AM, Hans Verkuil wrote:
> 
> 
> On 07/28/2016 11:49 PM, Lars-Peter Clausen wrote:
>> On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>>> to help enable asynchronous probe, however for built-in devices this requires
>>>>> very specific platform knowledge otherwise using async probe will blow up
>>>>> your kernel -- if you get it right though, using async probe can help with
>>>>
>>>> I'm not sure what specific platform knowledge you're thinking of here?
>>>> We have coverage for most things in the form of deferred probe (messy
>>>> though it is).
>>>
>>> Deferred probe is a complete a hack and sub-optimal.
>>
>> I fully agree. In the past though there were a few good attempts of
>> providing something better than probe deferral, but those were always
>> quickly shutdown by GregKH for failing to prove that probe deferral
>> really is insufficient.
>>
>> This probably an issue of presentation, but for future attempts it
>> should be kept in mind that hard numbers on why this is better greatly
>> improve the chance of it being accepted.
> 
> My main problem is not so much with deferred probe (esp. for cyclic dependencies
> it is a simple method of solving this, and simple is good). My main problem is
> that you can't tell the system that driver A needs to be probed after drivers B,
> C and D are probed first.
> 
> That would allow us to get rid of v4l2-async.c which is a horrible hack.
> 
> That code allows a bridge driver to wait until all dependent drivers are probed.
> This really should be core functionality.
> 
> Do other subsystems do something similar like drivers/media/v4l2-core/v4l2-async.c?
> Does anyone know?

drivers/base/component.c is a subsystem independent approach to the same
problem and is used by a few subsystems (primarily DRM).