Il sab 7 dic 2024, 16:43 Zhao Liu <zhao1....@intel.com> ha scritto:
> > 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
>
>
>
