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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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.

James