On 11/18/24 04:40, Paolo Bonzini wrote:
More reviews are welcome; in general, we should define a convention
for Rust functions and constants (is it okay to rename constants in
the Rust bindings if their C name is ugly? should functions keep or
lose the "qemu_*" prefixes?).
If the C name is ugly
On Mon, Nov 18, 2024 at 3:46 PM Manos Pitsidianakis
wrote:
> Yep, const fns are evaluated at compile time
This is not correct; "const fn"s *can* be evaluated at compile time.
In this case they won't since "self" is only available at run time.
The match statements persist in the final compiled cod
On Mon, 18 Nov 2024 13:40, Alex Bennée wrote:
>Manos Pitsidianakis writes:
>
>> DeviceId, which maps the peripheral and PCell registers of a PL011
>> device, was not treating each register value as a 32 bit value.
>>
>> Change DeviceId enum to return register values via constified getter
>> funct
On Mon, Nov 18, 2024 at 12:41 PM Alex Bennée wrote:
> This is a nice improvement in conciseness over the separate legs removed
> bellow.
>
> > +eprintln!("write bad offset {offset} at RO register
> > {dev_id:?} value {value}");
> > +}
>
> Is a binding for qemu_log and
Manos Pitsidianakis writes:
> DeviceId, which maps the peripheral and PCell registers of a PL011
> device, was not treating each register value as a 32 bit value.
>
> Change DeviceId enum to return register values via constified getter
> functions instead of leveraging the std::ops::Index<_> trai
DeviceId, which maps the peripheral and PCell registers of a PL011
device, was not treating each register value as a 32 bit value.
Change DeviceId enum to return register values via constified getter
functions instead of leveraging the std::ops::Index<_> trait.
While at it, print errors when gues
