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 A855B932 for ; Thu, 28 Jul 2016 10:50:52 +0000 (UTC) Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 73F79198 for ; Thu, 28 Jul 2016 10:50:51 +0000 (UTC) From: Laurent Pinchart To: ksummit-discuss@lists.linuxfoundation.org Date: Thu, 28 Jul 2016 13:51:02 +0300 Message-ID: <1745007.86gEd5I2vq@avalon> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Mauro Carvalho Chehab , "vegard.nossum@gmail.com" , "rafael.j.wysocki" , Marek Szyprowski , 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: , Hi Luis, On Wednesday 27 Jul 2016 09:50:04 Luis R. Rodriguez wrote: > (first e-mail bounced) > > Rafael has proposed has a set of patches to help deal with functional > dependencies between devices to help with power management. Mauro has > spoken briefly before over the media controller feature graph used to help > build relationship between complex dynamic dependencies. Dmitry has taken on > 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 boot. Even if you sort things out well -- there are current > limitations with ordering semantics available, case in point the x86 IOMMUs > already have a small sort run which expand beyond the core init entries > allowed, and on top of this the you still have device driver dependencies > which are implicitly setting order via link order: consider the ordering > between AMD IOMMUv1, AMD IOMMUv2, AMD KFD, and AMD radeon. This has made us > realize that at the module front the current 2 levels of init calls limits > our ordering semantics leaving only link order as a last measure when > things are built-in. Likewise I've recently have had to look into > dependency issues early in boot been due to differences between > paravirtualization and non-PV kernels, this lead to some current work to > help generalize custom section uses (linker tables) and then for us to > consider expanding x86 semantics early in boot to address some of the > shortcomings implicit by the some paravirtualized boot path. > > The goal behind Rafael's work's goal is essentially to avoid code > duplication (as without doing that in the core many drivers potentially > need to do the same thing in the same way) and help to address the > asynchronous system suspend/resume case that cannot be addressed by any > driver by itself anyway. The effort behind Rafael's, Mauro's, Dmitry's and > my work are all independent however the patterns are very similar: > addressing complex dependencies and relationships at run time and available > semantics for these. > > This begs a few questions: > > o Are there generic issues here ? > o Are there generic solutions possible ? > o What advanced techniques are out there to deal with this and how > are efforts in those domains going ? > > As an example of taste for the last item, consider Vegard Nossum's > involvement with a SAT solver (picosat) for AFL fuzzing with ext4 on > built-in kernels -- and the possibility to share some of the tools to > address some of the dependencies here. As it stands kconfig's semantics are > a bit of a mess, and in turn often tools have to do a bit of inference work > due to some of this, part if this problem is one reason why current > kconfig-sat efforts are a bit stalled. > > Benefits for addressing some of these topics generally has quite a bit of > uses in different domains: > > o Speeding up boot time > o Avoiding dead code, or correctness > o Shrinking kernel size > > This is a pretty generally broad topic, and it does cross subsystems, > I'm proposing it as a TECH TOPIC given that I had already poked Dmitry, > Mauro, and Rafael in February this year about a LPC microconference > about this sort of stuff as I thought that would have been a better venue -- > however even early then (February !) it seems they were busy with existing > LPC microconferences. I recently poked them and they seem to agree > discussing this somehow at KS would be good. Due to existing time > constraints at LPC, but given most interested folks may be at KS or > Plumbers, it'd be good to use shared time at KS and LPC to get folks to > organize ideas, problems, and solutions and in a more adhoc manner, and > then enable organically folks interested to organize and discuss short term > and long term roadmaps on respective work items. Its unclear yet if there > is a very CORE TOPIC here -- my guess would be that if there were we'd find > out at the next KS, but not this one. A workshop for this might help. > > Folks required to help with these topics: > > o Dmitry Torokhov (async probe) > o "Rafael J. Wysocki" (functional > dependencies) > o Marek Szyprowski (taking on some > of Rafael's previous work) > o Mauro Carvalho Chehab (feature graph) As the co-author of the media controller code (along with Sakari Ailus, based on a draft proposal from Hans Verkuil), I don't think MC will help here. It addresses very different problems, its purpose is to expose the topology of data flows inside a media device to userspace. The scope has recently been expanded slightly to also expose relationships between the hardware blocks and the kernel to userspace interfaces used to control them, but that's about it. We do have a fair share of probe ordering issues with media devices, especially in the embedded world where a device is made of many independent hardware pieces each represented by a struct device and bound to a driver, but MC only kicks in after probe to expose the device topology to userspace (and to some extent to control it when routing can be dynamic). This being said I'd be very interested in discussing asynchronous probing and probe ordering. I can also certainly bring media controller knowledge to the discussion, but I don't think that part would be very useful (apart possibly for saving everybody's time by explaining why MC isn't a solution to address those problems :-)). > o Vegard Nossum (SAT) > o Valentin Rothberg (wary of some > kconfig issues) -- Regards, Laurent Pinchart