On 10/1/24 10:54 AM, David Hildenbrand wrote:
On 30.09.24 23:49, Halil Pasic wrote:
On Fri, 27 Sep 2024 20:29:19 +0200
David Hildenbrand <da...@redhat.com> wrote:
On 27.09.24 20:20, Halil Pasic wrote:
On Wed, 11 Sep 2024 21:09:27 +0200
David Hildenbrand <da...@redhat.com> wrote:
[...]
That is a valid point. But IMHO the benefit of having this independent,
does not justify the churn of having a separate project with its
own governance, and communication infrastructure. And I suppose for an
open(?) specification, one would need those things.
I don't see the need to bring in all that bureaucracy. The original idea
was simple: if QEMU/TCG or QEMU/KVM implement a hypercall (IOW: it was
acked by the s390x maintainers), we document it somewhere.
Implementing something in QEMU and then modifying a KVM document in the
kernel tree sounded odd.
It is a valid question to ask: what if any other hypervisor
(cloud-hypervisor etc.) would want to implement a custom diag500
hypercall, and who would ack it. But I don't really think that we would
have to sort this out this at this point in time.
No strong opinions though. If Christian, Janosch and Claudio are in
favor of a separate "Specifications for open-source virtualization on
s390x (IBM z Systems)" project, I'm fine with it as well.
I'm more than happy if we don't need that. As said, I'm happy to
document wherever people tell me to document.
4 years ago we thought that having a separate repository was a good
idea, maybe it is no longer. In that case, s390x mainters please let me
know what to do :)
I'd like to at least have a partial documentation in the kernel if not a
full one. You can add a link to your repo to that.
Even if they go out of sync I'd rather have documentation where I'd
expect it (Linux) than only the repo. IMHO duplication isn't a gigantic
issue here.
We also have an internal space where KVM architecture is being stored
(currently a handful of documents) and we'll store it there as well,
including a link to the repo.
