Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor of Qemu configuration #2707
base: main
Are you sure you want to change the base?
Refactor of Qemu configuration #2707
Changes from 1 commit
af20343
5fa831a
28655d8
b85ab06
47d2741
0d37b78
1c61b38
525fd11
5346f83
17059d7
c50ba05
8d8631e
f2491c1
a12dc91
76480c1
46f0da7
3464e44
005475b
ea840cf
2998445
c5b3e19
0fe2977
b7f5240
413767f
8b04e3f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doens't the old API look better here? Can't we just keep Qemu::builder() and
.build()
then callsQemu::init_whatever
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, but the thing is that we need to separate the configuration step from the init step, and the builder generated by
typed-builder
is not made for this, it's a pain to move aroundThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO it's more important to have a good API than to have nice code "on the inside".
This is already what you're using (right?) idanarye/rust-typed-builder#80
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from the user's point of view, i think separating configuration from actual initialization is not so bad as well.
it makes more clear what the configuration part is and where qemu is actually getting initialized.
hiding something like qemu initialization in a
From
implementation doesn't sound good imhoThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it's really bad for users. We have builders everywhere in the codebase and they all work the same. There's no reason this shoudl work differently. You can still pass around an un-built builder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not migrate all uses of Qemu to Emulator directly? I (as a user) don't get the split between those two
I mean that's probably beyond the scope of this PR...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@domenukk the idea of
Qemu
is to have a 0-sized object giving a slightly higher-level interface to QEMU (basically making it more convenient to call to QEMU functions and providing a more rusty api), that can only be obtained when QEMU is correctly initialized.i use this trick a lot to give a
Qemu
as parameter for 0 cost.also (i may be wrong), i think it's nice to let the possibility to use QEMU without all the things in
Emulator
and still provide a usable API.in practice, i think you're right and most people will not want to use
Qemu
alone at all. the separation mostly exists to make it simpler to separate things and make it more clear what is specific to QEMU and what is higher-level stuff we introduce. A possible thing we can try is to moveQemu
andQemuHooks
tolibafl_qemu_sys
? at least it would remove the confusion betweenEmulator
andQemu
for users.@Marcondiro i thought about this, but i think it will be quite heavy to do in practice because
rust-typed-builder
adds up many generics internally that would be difficult to annotate explicitly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not make a builder for emulator instead, and remove qemu from the user-facing APIs then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, you're not married to typed_builder if it dropping it makes the API cleaner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
QemuConfig
is quite big, not using something liketyped_builder
would be a lot of work and make it less maintainable. idk of any other typed builder like this one.EmulatorBuilder
already exists btw, it's used to set things like the modules, snapshot engine, etc...QemuConfig
is just a programmatic way to set the cli of QEMU. if we continue to use the derive macro for getting qemu cli from QemuConfig, we need all the fields of the builder to be an option of the QEMU cli, hence the current split.