On 16.06.21 10:31, Linus Walleij wrote: > Hi Enrico, > So now there are two contesting patches for this and that creates a > social problem for us as maintainers. I am not too happy about that. note that this is a polished up of a repost of my original driver from last year. > Can we get the discussion down to actual technical points? Sure. Perhaps you recall or discussions from late 2020. The missing point there was (besides a few wording issues) the missing formal specification process w/ virtio TC. (spec was already included in this driver as well as the corresponding qemu patches). My spec was not just meant for VM applications but also actual silicon (as already mentioned, some folks of my client also implemented it in FPGAs - don't ask me about details, they just mentioned it was quite easy for them). This is why it is so trimmed on things like fixed packet size, unidirectional queues, mirroring packets w/ thus a few bits changed, etc. In constrast, a more network-like approach might have been looking nicer to traditional computer programmers, but much more complex to do in pure logic and eat up *lots of* more gates (think of actual memory management instead of hardwired latches, more complex decoding, etc). Meanwhile it played out working nicely in several HIL installations If I wanted to have a simple and CPU-only approach (just for VMs), I would have just mounted some sysfs pieces via 9P :p Several weeks ago, Viresh just wanted to continue the missing pieces (which was: tex'ifying the spec and submitting to virtio TC), but then unfortunately he invented something entirely different also put my name on it. Easy to imagine that I'm not amused at all. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
