search

arcnmx / qapi-rs

QEMU QMP and Guest Agent protocol for Rust
MIT License
44 stars 11 forks source link

Well done! #2

Open cholcombe973 opened 6 years ago

cholcombe973 commented 6 years ago

This is fantastic! I've been struggling with how to get this working on and off for a long time now: https://github.com/cholcombe973/parse_qapi and https://github.com/cholcombe973/qemu-rust. I started tinkering with it again yesterday but realized today you'd already done it. Is there anywhere I can help on this?

arcnmx commented 6 years ago

Thanks! It's fairly functional right now, and the best thing you could do it try to use it and see if there are any pain points with the way the API currently works, and as a sanity check to identify any possible bugs. A few things in particular that stand out to me:

cholcombe973 commented 6 years ago

Ok cool so there's a lot of places I can lend a hand. I also thought about creating some code to allow this to invoke qemu with various parameters.

arcnmx commented 6 years ago

Huh, now that would be an interesting project if we could parse QEMU's qemu-options.hx file into Rust types that could generate a qemu command-line. That interface is just as complex as qapi!

cholcombe973 commented 6 years ago

Wow what in the heck file format is this qemu-options.hx file in? I've never seen something like this before. If I could parse this crazy file I'd have something way better than the manual thing I was working on

arcnmx commented 6 years ago

I have no idea to be honest. It certainly looks structured enough to be usable for us to parse, but I'm not really sure how that file turns into an option parser in qemu itself.

cholcombe973 commented 6 years ago

I wonder if something like peg could be useful here.

arcnmx commented 6 years ago

Hm, see qemuopts. Maybe the .hx file is only for generating texinfo documentation? Though it's probably better than trying to parse the C structs strewn throughout the codebase.

As for peg, maybe, it's probably just up to personal preference/comfort whether to use something like it or nom.

cholcombe973 commented 6 years ago

The blocks seem to be defined by STEXI and ETEXI. I'll play around a little and see what i can do with this

arcnmx commented 6 years ago

Hm yeah, it does look mostly freeform texinfo, so it's hard to say whether it's strict/structured enough to be parsed without fuzzing in some places... The real structured data is indeed scattered in the C source files ><

jnsnow commented 5 years ago

For what it's worth, QEMU itself has wanted to refactor its option parsing and documentation very badly for a very long time, but the subsystems in QEMU are so diverse as to be almost entirely fractured; so any sweeping changes to the options management wind up requiring a lot of specific knowledge of arcane modules to bring about fully.

Not to mention that we did not have a real deprecation policy until quite recently; and we have many existing legacy users who rely on some commands that are actually quite difficult to support.

It's not something I get to spend much of my time on, but better documentation for QEMU and as a result a more mechanical, data-driven schema for the QEMU command-line that ties into the QAPI schema is on my mind, but it's a huge project. KVM Forum 2019 is coming up and it will for sure be on my list of things to talk about to see if we can't come up with some plans to modernize our documentation and interface specifications.

jnsnow commented 3 years ago

Two years later: I spend a LOT of time on this now. We are actively refactoring our command line parsing and marching towards a version of QEMU that can be configured entirely through QMP, at which point the desire for parsing command line options in this library will be moot.

I happen to know that elmarco has also been experimenting with generating QAPI types directly into rust using our in-tree QAPI generator (Python). Perhaps there is some synchronicity possible there.