Should we make mark_param_change buffer implementation internal?

Should we make mark_param_change buffer implementation internal?

[Lars-Peter Clausen]

Hi,

Right now we have a mark_param_change callback in the buffer access
functions struct, which should be called whenever the parameters (length,
bytes per datum) of the buffer change. Each buffer implementation calls
their own mark_param_change callback in their set_length and
set_bytes_per_datum callbacks. Additionally mark_param_change gets called
when the user changes the buffer length. So in this case it will get called
twice.

So I'm wondering if we should make it completely buffer implementation
internal and not export it in the buffer access functions struct, since the
buffer implementation will probably know best anyway if one of it's
parameters has changed.

- Lars

Re: Should we make mark_param_change buffer implementation internal?

[Jonathan Cameron]

Lars-Peter Clausen <lars@metafoo.de> wrote:

>Hi,
>
>Right now we have a =
mark_param_change callback in the buffer access
>functions struct, which sh=
ould be called whenever the parameters
>(length,
>bytes per datum) of the b=
uffer change. Each buffer implementation calls
>their own mark_param_change=
 callback in their set_length and
>set_bytes_per_datum callbacks. Additiona=
lly mark_param_change gets
>called
>when the user changes the buffer length=
. So in this case it will get
>called
>twice.
>
>So I'm wondering if we sho=
uld make it completely buffer implementation
>internal and not export it in=
 the buffer access functions struct, since
>the
>buffer implementation will=
 probably know best anyway if one of it's
>parameters has changed.

Makes s=
ense. 
>
>- Lars
>--
>To unsubscribe from this list: send the line "unsubsc=
ribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>Mor=
e majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent f=
rom my Android phone 
with K-9 Mail. Please excuse my brevity.