> impl IntegerExt for u64
> {
> fn deposit(self, start: usize, length: usize, fieldval: u64) -> u64 {
> /* FIXME: Implement a more elegant check with error handling support? */
> assert!(length > 0 && length <= 64 - start);
>
> let mask = (u64::MAX >> (64 - length)) << start;
> (value & !mask) | ((fieldval << start) & mask)
> }
> }
Then C and Rust would be using completely different bitops library, is
it necessary to implement the C interface directly in Rust instead of
keeping the C implementation (when Rust is enabled)?
If it's domain specific (related to emulation) then it's better to avoid duplication but In some cases it's unavoidable: for example very very simple inlines (e.g. clock_get_hz for an example) or simple forwarding APIs like the various timer_init variants. It's simpler to redo the forwarding in Rust and only write the callback translation once, than to repeat many times the code to translate the callbacks and forward each init variant to the corresponding C function.
Paolo
> And we can add a "prelude" module so that you can do
>
> use qemu_api::prelude::*;
>
> and get all these useful traits at once. I will send a patch after
> fleshing the idea out a bit more.
Thanks! Cross fingers.
Regards,
Zhao