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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Friday 29 Jul 2016 09:55:58 Lars-Peter Clausen wrote:
> 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).

If we decide to keep v4l2-async (which is an issue to be discussed on its 
own), we should probably replace it with the component framework. That might 
require modifications to the component framework that could affect other 
subsystems though, last time I looked v4l2-async had a few additional features 
(but that was a while ago).

-- 
Regards,

Laurent Pinchart