On 14-06-21, 11:17, Enrico Weigelt, metux IT consult wrote: > On 14.06.21 10:12, Andy Shevchenko wrote: > > > That's why we have a thing called standard. And AFAIU virtio API/ABIs > > should be officially registered and standardized. > > Absolutely. > > I've submitted my spec to virtio folks last nov, but this wasn't in form > of patch against their tex-based documentation yet (just ascii text), > thus laying around in the pipeline. > > (meanwhile the actual implementation is running in the field for over > 6 month now) > > Viresh picked it up, but made something totally different out of it. > I wonder why he didn't consult me first. Here I asked you on 26th of May, if you would be fine if I take it forward as you didn't do anything with it formally in the last 5-6 months (Yes I know you were busy with other stuff). https://lore.kernel.org/linux-doc/20210526033206.5v362hdywb55msve@vireshk-i7/ You chose not to reply. I did the same before picking up the kernel code. You chose not to reply. I am not inclined to do offlist discussions as they aren't fruitful eventually, and it is better to do these discussions over open lists, so others can chime in as well. > All that needed to be done was > translated the ascii documentation into tex and rephrase a bit in order > to match the formal terminology and structure used in virtio specs. Not really. There were things lagging, which are normally caught in reviews and fixed/updated. But that never happened in this case. You only sent the specs once to virtio list, that too as an attachment and it never made it to the virtio guys there (as the list doesn't take attachments). https://www.mail-archive.com/virtio-dev@xxxxxxxxxxxxxxxxxxxx/msg06946.html > This makes me very unhappy. I know you have solutions running in products which depend on the layout of the config structure or request/responses, based on your original write-up, but unless something is merged in open source code or specification, it is going to get changed, normally because of reviews. And you will be required to change things based on reviews, you just can't say that I have products running the code and so I won't change it. That is why people say, Upstream first. So you don't get into this mess. Yes, this is tough and that's the way it is. You keep saying that I have changed the original specification too much, which is incorrect, I tried to point out earlier what all is changed and why. https://lore.kernel.org/linux-gpio/CAKohpokxSoSVtAJkL-T_OOoS8dW-gYG1Gs5=_DwebvJETE48Xw@xxxxxxxxxxxxxx/ You chose not to reply to that. Lemme say this again. This is a generic protocol we are trying to define here. It needs to take everyone's view into account and their use cases. We are required here to collaborate. A solution thought to be good enough for one person or use-case, isn't going to fly. The changes I did to it are required to make it useful for the generic solution for a protocol. I am sure there would be shortcomings, like the one identified by Jean-Philippe Brucker, where he asked to add offset of the gpios-name thing. He made a sensible suggestion, which I am required to incorporate. I just can't reply to him and say I won't change it because I have already designed my product based on this. Lets try to improve the code and specification here and make it work for both of us by giving very specific feedback on wherever you think the protocol or code is not efficient or correct. Being unhappy isn't going make anything better. -- viresh _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
