> GVM isn't built in a way which is usable by any other project. That's ok, but it does nothing to explain the design decision. It is. You configure a YAML/JSO

> GVM isn't built in a way which is usable by any other project. That's ok, but it does nothing to explain the design decision. It is. You configure a YAML/JSON file to define the mdev types that are presented by the vendor driver in the standard sysfsdev mdev_bus path. Those appear precisely the same way any mdev type appears to any program which uses the VFIO-Mdev API. In other words you can install GVM/Mdev-GPU underneath Libvirt or talk to it using mdevctl. > You create mediated devices for nVidia devices by sending ioctls exposed via RMAPI. This is potato/potato. The explanation you just gave STILL makes it sound as if this is a novel thing done by GVM/mdev-gpu rather than something common, and talking down to someone who is asking informed questions about why you did it this way by linking to internals (when I was physically there for most of those talks and helped write some of the docs) doesn't paint a pretty picture. This isn't potato/potato. All of these functions are artificially locked out on closed source programs that gatekeep the ability to use your own GPU. No, we're not making it sound like something special. All of our documentation that you seem to think linking to amounts to "talking down to you" because of your position in industry references common virtualization APIs in the kernel and drivers. We link to sample code on how to talk to those APIs. If anything we're showing people this stuff isn't magic! That's the whole point of doing this as open source and making it work on everything we can rather than making it closed source and locking it out to certain devices then charging you for the use of your own hardware. > NONE OF THE STUFF I'M ASKING ABOUT IS DOCUMENTED OR SPELLED OUT. That's the point. From someone who was a maintainer, engineering leader, etc on a major open source virtualization platform who literally wrote code which does this kind of scheduling/creation across a cluster I'm glad you have no problem gatekeeping in your comments or propping yourself up based on your job history. Many folks have offered constructive criticism as well as guidance on where to place our attention next many of whom I strongly suspect are at least as experienced as you (those folks who notably don't feel the need to often repeat how senior they are) but thanks again for the grandstanding so plainly. >I am telling you that your documentation is opaque, misleading, takes credit for things you did not invent No it doesn't. I constantly link to everything we're talking about on OpenMdev and to all the original sources, talks, mailing list posts, sample code. Please find any example you like of inappropriately taking credit for things and I'll happily correct it. > where that "missing middle" is /sys/devices/.../mdev_supported_types[/...] and "echo|uuidgen"), etc. This comment makes no sense. /sys/devices/.../mdev_supported_types[/...] and "echo|uuidgen" has nothing to do with GVM/Mdev-GPU. > This is, or could be, a great start to a unified ecosystem. You are going to have a very hard time getting a developer/user ecosystem if you do not provide better documentation, I agree we need to improve our documentation a lot still yet. It's open for community contribution. You obviously have some idea of what you're talking about enough that we can have this argument so as much as this has dragged on for an uncomfortable amount of time and I still think you have several fundamental misconceptions about what GVM/Mdev-GPU actually does it would be nice if I could structure this interaction with you into something I could use to condense what you're saying here into documentation improvements rather than a flame war in a web forum comment section. > and most of all, to acknowledge the work other have done/the knowledge they have rather than presenting any of this like it's brand new or novel. It could be a great utility. Or it could be something no other project ever uses. That's up to you. We're CONSTANTLY citing sources on OpenMdev.io and in our other project (LibVF.IO which is again unrelated to this thread) as I said we mention all the other open sources we deal with by name multiple times in the install article and also link them at the bottom of the article again. I even dedicate a section of all of our open source talks (FOSDEM/X.org) just to thanking the authors of those projects! I mention them by name in those talks as well multiple times! https://www.youtube.com/watch?v=xbVKMQ1Rz2Y https://www.youtube.com/watch?v=xbVKMQ1Rz2Y https://www.youtube.com/watch?v=8pVrTyLqV_I https://www.youtube.com/watch?v=8pVrTyLqV_I The whole point here is to make it clear to folks this stuff is NOT MAGIC. It's easy to understand and we show exactly how it works to the best of our ability citing sources for all the documents as well as literally linking to code samples on how to write your own programs against these APIs and making our own programs available as free open source software that makes this work on most hardware. > My comments are not intended to be trollish. They are intended to tell you "as someone who has written very similar code and done very similar things for a long time, the only way to figure out what the hell any of this was supposed to do was to literally read the source and make educated guesses". The average developer/user is not going to have the knowledge base to make those guesses at all First off you don't have to read the source and make an educated guess because we've gone and done the work of building an implementation for you that does the things you're not allowed to do by design (anti-user limitations). We do have work to do on improving our documentation. > but they may see references to "arcd ..." like it's "developer documentation", go find it, and ask "why the hell is this managing qemu directly instead of libvirt", or "why is no libvirt XML/qemu hook provided"? I really am getting tired of explaining that GVM/Mdev-GPU IS NOT LibVF.IO and it has zero integration with it. GVM/Mdev-GPU works with anything that works with the VFIO-Mdev API including Libvirt/Virsh/Virt-Manager. I really hope by the next round of comments this point is very clear so I don't need to retread this point yet again. > I know yours is new, but these are of unusually low quality for a submission to HN, and doubling down with links to the same inadequate docs like everyone you're talking to is a moron doesn't help your reputation. Additionally, examples. I fail to see specifically how the links are inadequate in the context in which I've linked them other than taking your word for it. I know we're missing things - they don't cover every category of knowledge yet but I'm trying to improve upon them and do them as openly as possible so other folks can benefit from them/help as they like. I don't think everyone is a moron and I'm literally trying to share everything I learn because I believe that's the best way to lift people up, but my guess is you think I am a moron because you seem to assert the same falsehoods over and over despite that they've been corrected more than once (GVM/Mdev-GPU is not operable with Libvirt / LibVF.IO is related to GVM/Mdev-GPU / GVM/Mdev-GPU could be a PR to mdevctl - a bash script for echoing values into sysfsdev mdev_bus). > Additionally, examples. And reach out to others -- proxmox, ovirt, xcp, openstack (nova). See if you can collaborate. This will mean using (or at least providing) libvirt bindings/XML snippets like everyone else. It will be worth it. I'm trying to talk with everyone I can talk to. There have been some folks from some larger projects (QubesOS, Xen Project, OpenXT) offering their mentorship and who have given countless hours to offering advice - To them I've very grateful and I always hope to expand that circle. Besides the public community discussion threads in IRC/Discord we have community calls on the first Wednesday of every month.