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 3E8FA941 for ; Tue, 2 Aug 2016 08:58:03 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4074721A for ; Tue, 2 Aug 2016 08:58:02 +0000 (UTC) Date: Tue, 02 Aug 2016 10:57:59 +0200 Message-ID: From: Takashi Iwai To: Lars-Peter Clausen In-Reply-To: References: <93f7ce34-c2e9-583f-2e6f-1f23ae76a761@xs4all.nl> <20160801105531.2687069a@recife.lan> <579F6049.9030408@samsung.com> <63f6e3b4-3a48-182f-e8d5-87e720b60d5d@metafoo.de> <579F6C00.502@samsung.com> <579F766F.1000605@samsung.com> <20160801170613.GV10376@sirena.org.uk> <579F9613.4020805@samsung.com> <20160801184832.GA10376@sirena.org.uk> <579FA631.9050702@samsung.com> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: ksummit-discuss@lists.linuxfoundation.org, Mauro Carvalho Chehab , "vegard.nossum@gmail.com" , "rafael.j.wysocki" , Valentin Rothberg , Marek Szyprowski 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 Mon, 01 Aug 2016 22:05:49 +0200, Lars-Peter Clausen wrote: > > On 08/01/2016 09:42 PM, Andrzej Hajda wrote: > > On 08/01/2016 08:48 PM, Mark Brown wrote: > >> On Mon, Aug 01, 2016 at 08:33:55PM +0200, Andrzej Hajda wrote: > >>> On 08/01/2016 07:06 PM, Mark Brown wrote: > >>>> The device isn't supposed to work, just not crash - this is mainly used > >>>> for things that are exposed to userspace where we need to keep returning > >>>> errors to userspace until they free their reference. I'm not sure we > >>>> can get out of that one. > >>> Could you give some examples? I suppose this is slightly different issue > >>> than unbinding provider of working resource. > >> Anything where you have a resource open from userspace pretty much - a > >> file stored on media that got removed for example. The struct > >> representing the open file handle needs to be valid as long as the file > >> is open. > > > > It seems to be not related directly to the subject - file handle is > > something > > created/controlled by userspace, as well as it's life-time. > > I see no real device dependency here. I guess Lars though rather about > > ghost resources like in clock framework, when after removing provider, > > clock ops are replaced by phony ops. > > Both really. In the end they both boil down to the same problem. You have > provider and a consumer and the provider disappears while the consumer still > uses it. In this case the kernel is the provider and userspace the consumer. > > We should try to address both issue within the same framework, especially > since there is a dependency chain. Lets say a audio device uses a clock and > the clock becomes unavailable this means the the audio device is no longer > usable for a userspace application. > > When I meant there are multiple options I did not mean that we must choose > one of these options and always use it and never use the others. A solution > will most likely involve multiple of them at different levels in the stack. > > There have been attempts or ideas in the past to push the handling of > keeping the file descriptor alive while having operations return errors > directly into the fs layer so that individual frameworks don't have to deal > with it. See https://lwn.net/Articles/546537/ FWIW, ALSA core code does a similar workaround already, and it's proven to work fine for over a decade. Takashi