I finally got around to read this slowly. Thank you, Fan and Jonathan! I'm getting some "incomplete" vibes: "if we ever implement", "patches for this on list", "we aren't emulating this yet at all", and ...
Jonathan Cameron <jonathan.came...@huawei.com> writes: [...] > Only thing I'd add is that for now (because we don't need it for testing > the kernel flows) is that this does not provide any way for external > agents (e.g. our 'fabric manager' to find out what the state is - i.e. > if the extents have been accepted by the host etc). That stuff is all > defined by the spec, but not yet in the QMP interface. At somepoint > we may want to add that as a state query type interface. ... this, too. In review of v5, I asked whether this interface needs to be stable. "Not stable" doesn't mean we change an interface without thought. It merely means we can change it much, much faster, and with much less overhead. I understand you want it chiefly for CXL development. Development aids commonly don't need to be stable. If you're aiming for stable, you need to convince us the interface can support the foreseeable purposes without incompatible changes. In particular, I'd like to see how you intend to support "finding out what the state is". I suspect that's related to my question in review of v8: how to detect completion, and maybe track progress. There's infrastructure for background jobs: job.json. We might be better off using it, unless completion is trivial and progress tracking unnecessary. [...]
