From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9107C71 for ; Tue, 9 Aug 2016 16:08:43 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C2A5225B for ; Tue, 9 Aug 2016 16:08:41 +0000 (UTC) Message-ID: <1470758919.2299.46.camel@HansenPartnership.com> From: James Bottomley To: =?ISO-8859-1?Q?J=F6rg_R=F6del?= , "Luis R. Rodriguez" Date: Tue, 09 Aug 2016 09:08:39 -0700 In-Reply-To: <20160809095728.GE30880@suse.de> References: <20160727172636.GM11806@sirena.org.uk> <20160727175829.GG5537@wotan.suse.de> <579A7DFD.60305@metafoo.de> <98eb563b-5d62-74df-692a-f2aa4f7b07b8@xs4all.nl> <20160729111303.GA10376@sirena.org.uk> <20160801190309.GX3296@wotan.suse.de> <20160809095728.GE30880@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: Oded Gabbay , ksummit-discuss@lists.linuxfoundation.org, Mauro Carvalho Chehab , "vegard.nossum@gmail.com" , "rafael.j.wysocki" , Cristina Moraru , Roberto Di Cosmo , Marek Szyprowski , Stefano Zacchiroli , Valentin Rothberg Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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