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

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Tue, Aug 09, 2016 at 09:11:00AM -0700, James Bottomley wrote:
> On Tue, 2016-08-09 at 09:08 -0700, James Bottomley wrote:
> > On Tue, 2016-08-09 at 11:57 +0200, Jörg Rödel wrote:
> > > On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez wrote:
> > > > Another piece of code that deals with complex dependencies I've
> > > > recently
> > > > ventured into was the x86 IOMMU stuff. The complexities here are
> > > > both at
> > > > the built-in init level and also later at probe.
> > > 
> > > Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 driver 
> > > are built as modules, as the order of loading these modules is
> > > preserved by symbol dependencies. But when they are built-in these
> > > modules also need to be initialized in the right order, otherwise
> > > the
> > > KFD-driver will call into an uninialized IOMMU driver and crashes
> > > the
> > > system. Long-term this will be fixed by always build-in the IOMMU
> > > -parts (when they are merged with the Intel-SVM support), but in 
> > > general not being able to express dependencies between build-in 
> > > modules remains to be a problem.
> > 
> > Have you considered using transport templates or attribute 
> > containers?  That's how we manage the complex hierarchies in 
> > ATA/SCSI.  If you look we have a complex dependency
> > 
> > ata_dev->transport->ata->scsi (or in SCSI dev->transport->scsi)
> > 
> > Our chains are much more complex than this because I've stopped 
> > before probing begins, which is async.
> > 
> > The basic way we cope is that both ata and scsi use subsystem_init 
> > for their exclusive resources, meaning they're order independent. The
> > probes a kicked off by the hardware modules, so they're done by
> > module_init (meaning after subsystem_init) again, order independent. 
> >  The rest of the dependent initialisations is done within the
> > transport/attribute code, meaning not until a consumer is actually
> > instantiated.
> > 
> > The way attributes/transport classes work is that they're actually
> > attached to the devices that you instantiate
> 
> Hmm, pressed send to early.  However, the basic point is that you can
> finesse most of the "dependency" issues by separating the
> initalisations into a subsystem part (which is guaranteed before any
> device is probed) and a device part, which can be done at device
> instantiation time.

This sounds pretty great, what other subsystems use it and most
importantly, why haven't others picked this up yet ?

  Luis