On Wed, Sep 18, 2019 at 8:45 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
>
> I propose the following (assuming Linus isn't cranky enough to refuse
> the entire iomap patchpile forever):
Since I don't think the code was _wrong_, it was just that I didn't
want to introduce a new pattern for something we already have, I'd be
ok with just a fix patch on top too.
And if the xfs people really want to use the "pop" model, that's fine
too - just make it specific to just the iomap_ioend type, which is all
you seem to really want to pop, and make the typing (and naming) be
about that particular thing.
As mentioned, I don't think that whole "while (pop)" model is _wrong_
per se. But I also don't like proliferating new random list users in
general, just because some subsystem has some internal preference.
See?
And I notice that one of the users actually does keep the list around
and modifies it, ie this one:
while ((ioend = list_pop_entry(&tmp, struct xfs_ioend, io_list))) {
xfs_ioend_try_merge(ioend, &tmp);
xfs_end_ioend(ioend);
}
actually seems to _work_ on the remaining part of the list in that
xfs_ioend_try_merge() function.
So inside of xfs, that "pop ioend from the list" model really may make
perfect sense, and you could just do
static inline struct xfs_ioend *xfs_pop_ioend(struct list_head *head)
{
struct xfs_ioend *ioend = list_first_entry_or_null(head,
struct xfs_ioend *, io_list);
if (ioend)
list_del(&ioend->io_list);
return ioend;
}
and I don't think it's wrong.
It's just that we've survived three decades without that list_pop(),
and I don't want to make our header files even bigger and more complex
unless we actually have multiple real users.
Linus
