On Thu, Feb 29, 2024 at 1:57 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Thu, 29 Feb 2024 at 04:52, Joe Komlodi <koml...@google.com> wrote: > > On Wed, Feb 28, 2024 at 6:21 AM Peter Maydell <peter.mayd...@linaro.org> > > wrote: > > > So as far as I can see, this patchset defines a bunch of mechanism, > > > but no actual users: no device looks at these new memattrs, no board > > > code sets the properties. I don't really want to add this without > > > an upstream usecase for it. > > > > Yeah, I believe the current use-cases for this series are mostly downstream. > > It's possible that there's an upstream device that might benefit from > > it, but I'm not aware of one. > > > > Is the concern the usefulness of the series, or the worry about it > > bit-rotting? > > If it's the latter, would a qtest be alright to make sure it doesn't rot? > > My main issues are: > * it's hard to review design without the uses of the code > * it's extra complexity and maintenance burden that we don't > need (upstream): accepting the patches gives upstream extra > work to deal with into the future with no benefit to us > * dead code is code that typically we would remove > * we end up with something we can't refactor or clean up > or change because the only reason we have it is for code > that we don't have any visibility into: effectively it > becomes an API for us that we can't change, which is not > something QEMU does except for specific well defined API > surfaces (QMP, plugins, etc) > > Our usual approach is "submit the patches that add the new core > feature/mechanism along with the patches that add the new > device/board/etc that uses it". Compare the recent patches > also from Google for the ITS and SMMU that try to add hooks > that aren't needed by anything in upstream QEMU: > https://patchew.org/QEMU/20240221171716.1260192-1-nabiheste...@google.com/20240221171716.1260192-3-nabiheste...@google.com/ > https://patchew.org/QEMU/20240221173325.1494895-1-nabiheste...@google.com/20240221173325.1494895-3-nabiheste...@google.com/ > -- we rejected those for the same reason.
Makes sense! Thanks for taking the time to look over them. - Joe > > thanks > -- PMM
