> > > Would it be possible
> > > to extend the shared list.h helpers (might this contain functionality
> > > interesting to other drivers as well)?
> >
> > Hm, not without making them more complex I'm afraid. And since
> > most users are happy with the current implementation I'm not entirely
> >
On Tue, 13 Aug 2019 22:25:49 +0200
Boris Brezillon wrote:
> On Tue, 13 Aug 2019 12:59:03 -0700
> Alyssa Rosenzweig wrote:
>
> > Could you explain a little bit more why this is neded? What do these
> > helpers do that the generic list.h helpers can't?
>
> The _safe attribute in generic helper
> > Could you explain a little bit more why this is neded? What do these
> > helpers do that the generic list.h helpers can't?
>
> The _safe attribute in generic helpers is just about handling the case
> where the current item is removed from the list (or a new one is
> inserted and you want to sk
On Tue, 13 Aug 2019 12:59:03 -0700
Alyssa Rosenzweig wrote:
> Could you explain a little bit more why this is neded? What do these
> helpers do that the generic list.h helpers can't?
The _safe attribute in generic helpers is just about handling the case
where the current item is removed from the
Could you explain a little bit more why this is neded? What do these
helpers do that the generic list.h helpers can't? Would it be possible
to extend the shared list.h helpers (might this contain functionality
interesting to other drivers as well)?
What about the new next_ins argument -- should th
The generic list helpers are too restrictive for us: we want to be
able to update the instruction pointer within the foreach body, and the
list_assert() check done in list_for_each_entry() prevents it.
Sometimes we also want to update the next_ins pointer (in case we
delete/replace the next instruc
