Note particularly the comment about racy lookups; I don’t immediately know what to do there.

Maybe we can change the callers instead — I see only Podman’s Mount and Unmount, maybe those could get a ListImagesByNames with one set of features, and everyone else could get an ListAllImages with the names parameter removed entirely.

We need to resolve this somehow, I didn’t analyze the callers enough to have an opinion yet.

As a general principle, a commit should go from a buildable (ideally, working) codebase to a buildable codebase; don’t split a change of a function parameter from updates of callers into separate commits. (The reason is to make git bisect work well, and to generally make it possible to do backports without having to think too much about the commit sequence.)

.

Great, that solves that problem.

Now, can we fix the other one as well, and do the filtering based on the same layerTree? I think this should work:

• Have compileImageFilters also return a “needs a layer tree” boolean
• Add a *layerTree parameter to filterFunc; move tree creation from compileImageFilters to filterImages (based on the boolean from the previous step)
• Then move compileImageFilters directly into ListImages, and call it before the MultiList
• MultiList will now know whether a layerTree is necessary, and always create only one.

This is getting a bit large — can this be split into at least 3 commits?

• Add ListImagesByNames, change the ListImages API, without changing the implementation
• Refactor filterImages + filterFunc to create the tree in filterFunc
• Use MultiList, and all the other stuff.

Thanks! ACK overall, just some nits to help future maintainers.

LGTM.

Great work!