[alsa-devel] [PATCH 03/25] ALSA: firewire-lib: add helper functions for asynchronous MIDI port

[Takashi Iwai]

On Sun, 16 Aug 2015 14:15:09 +0200,
Stefan Richter wrote:
> 
> On Aug 16 Takashi Iwai wrote:
> > On Sat, 15 Aug 2015 12:15:54 +0200,
> > Stefan Richter wrote:
> > > 
> > > On Aug 13 Takashi Sakamoto wrote:
> > > > On Aug 13 2015 15:31, Takashi Iwai wrote:
> > > > > On Thu, 13 Aug 2015 02:19:59 +0200,
> > > > > Takashi Sakamoto wrote:
> > > > >> +	generation = port->parent->generation;
> > > > >> +	smp_rmb(); /* node_id vs. generation */
> > > > >
> > > > > Why this barrier is needed?
> > > > 
> > > > Oops. I forgot to refine it after copying from the other place. Exactly, 
> > > > it's not need here.
> > > > 
> > > > >> +	fw_send_request(port->parent->card, &port->transaction, type,
> > > > >> +			port->parent->node_id, generation,
> > > > >> +			port->parent->max_speed, port->addr,
> > > > >> +			port->buf, port->len, async_midi_port_callback,
> > > > >> +			port);
> > > > >> +}
> > > 
> > > The barrier is normally needed because:
> [there is a dependency between node_ID and generation and]
> > >   - The node_ID:generation tuple is accessed in the Linux firewire stack in
> > >     a lockless manner:
> [...]
> > Thanks, that clarifies.  But wouldn't it be more helpful to have some
> > macro than open-coding at each place?
> 
> I agree that a cooked-up accessor via <linux/firewire.h> would be good,
> but I have no immediate idea how that accessor should look like.  Looking
> at the various uses of fw_send_request
> [http://lxr.free-electrons.com/ident?i=fw_send_request],
> it's clear that this API between protocol drivers and firewire-core is
> quite low-level and flexible by nature.  In particular, the different users
> of the API take node_id:generation from different sources.¹  

Argh, I somehow expected that the accesses are done in more or less in
the same struct or device object.  Then it'll be tricky, indeed.

> As mentioned, another way would be to fuse node_id:generation into a single
> atomic datum throughout all firewire drivers.  I.e. instead of ensuring the
> proper access order everytime, just access both data simultaneously
> everytime.  Not having tried this yet, I am not sure which way would be
> more readable.

Yeah, having a common tuple might things a bit easier to manage, I
suppose.  But I'm not familiar with the firewire code in general, so
don't count this as a serious evaluation at all ;)


thanks,

Takashi