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

[Takashi Iwai <tiwai@suse.de>]

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