Hey Zhao,
On Thu, 11 Jul 2024 at 07:05, Zhao Liu wrote:
>
> Hi Manos and all,
>
> On Tue, Jun 11, 2024 at 01:33:32PM +0300, Manos Pitsidianakis wrote:
> > diff --git a/rust/rustfmt.toml b/rust/rustfmt.toml
> > new file mode 100644
> > index 00..ebecb99fe0
> > --- /dev/null
> > +++
Hi Manos and all,
On Tue, Jun 11, 2024 at 01:33:32PM +0300, Manos Pitsidianakis wrote:
> diff --git a/rust/rustfmt.toml b/rust/rustfmt.toml
> new file mode 100644
> index 00..ebecb99fe0
> --- /dev/null
> +++ b/rust/rustfmt.toml
> @@ -0,0 +1,7 @@
> +edition = "2021"
>
Il mer 19 giu 2024, 18:54 Daniel P. Berrangé ha
scritto:
> >build/
> > rust/
> >.cargo/
> > config.toml # generated by configure or meson.build
> >Cargo.toml # workspace generated by configure or meson.build
> >Cargo.lock # can be either
On Wed, Jun 19, 2024 at 06:43:01PM +0200, Paolo Bonzini wrote:
> On 6/19/24 07:34, Richard Henderson wrote:
> > First silly question: how much of this is boiler plate that gets moved
> > the moment that the second rust subdirectory is added?
>
> If my suggestion at
>
On 6/19/24 07:34, Richard Henderson wrote:
First silly question: how much of this is boiler plate that gets moved
the moment that the second rust subdirectory is added?
If my suggestion at
https://lore.kernel.org/qemu-devel/CABgObfaP7DRD8dbSKNmUzhZNyxeHWO0MztaW3_EFYt=vf6s...@mail.gmail.com/
On 6/11/24 03:33, Manos Pitsidianakis wrote:
This commit adds a re-implementation of hw/char/pl011.c in Rust.
It uses generated Rust bindings (produced by `ninja
aarch64-softmmu-generated.rs`) to
register itself as a QOM type/class.
How to build:
1. Make sure rust, cargo and bindgen (cargo
On Tue, 18 Jun 2024 at 10:30, Paolo Bonzini wrote:
>
> On Tue, Jun 18, 2024 at 11:13 AM Daniel P. Berrangé
> wrote:
> > I wonder if starting with a device implementation is perhaps the
> > wrong idea, in terms of a practical yet simple first step.
> >
> > As devices go, the pl011 device is
On Tue, Jun 18, 2024 at 11:13 AM Daniel P. Berrangé wrote:
> I wonder if starting with a device implementation is perhaps the
> wrong idea, in terms of a practical yet simple first step.
>
> As devices go, the pl011 device is simple, but compared to other
> QOM impls in QEMU, devices are still
On Mon, Jun 17, 2024 at 01:32:54PM +0200, Paolo Bonzini wrote:
> Il lun 17 giu 2024, 10:59 Manos Pitsidianakis <
> manos.pitsidiana...@linaro.org> ha scritto:
>
> > >qdev_define_type!(c"test-device", TestDevice);
> > >impl ObjectImpl for TestDevice {}
> > >impl DeviceImpl for TestDevice {}
> > >
Il lun 17 giu 2024, 23:45 Manos Pitsidianakis
ha scritto:
> Secondly, are you implying that these callbacks are not operated under
> the BQL?
No, I'm implying that if you had the following nested calls:
unsafe read callback receives the opaque point
-> cast to to call safe read callback
On Tue, Jun 18, 2024 at 1:33 AM Pierrick Bouvier
wrote:
>
> On 6/17/24 14:04, Manos Pitsidianakis wrote:
> > On Mon, 17 Jun 2024 17:32, Paolo Bonzini wrote:
> >> On Mon, Jun 17, 2024 at 4:04 PM Manos Pitsidianakis
> >> wrote:
> >>> I respectfully disagree and recommend taking another look at
On 6/17/24 14:04, Manos Pitsidianakis wrote:
On Mon, 17 Jun 2024 17:32, Paolo Bonzini wrote:
On Mon, Jun 17, 2024 at 4:04 PM Manos Pitsidianakis
wrote:
I respectfully disagree and recommend taking another look at the code.
The device actually performs all logic in non-unsafe methods and is
On 6/17/24 07:32, Paolo Bonzini wrote:
On Mon, Jun 17, 2024 at 4:04 PM Manos Pitsidianakis
wrote:
I respectfully disagree and recommend taking another look at the code.
The device actually performs all logic in non-unsafe methods and is
typed instead of operating on raw integers as
On Mon, 17 Jun 2024 17:32, Paolo Bonzini wrote:
On Mon, Jun 17, 2024 at 4:04 PM Manos Pitsidianakis
wrote:
I respectfully disagree and recommend taking another look at the code.
The device actually performs all logic in non-unsafe methods and is
typed instead of operating on raw integers as
On Mon, Jun 17, 2024 at 4:04 PM Manos Pitsidianakis
wrote:
> I respectfully disagree and recommend taking another look at the code.
>
> The device actually performs all logic in non-unsafe methods and is
> typed instead of operating on raw integers as fields/state. The C stuff
> is the FFI
On Mon, 17 Jun 2024 14:32, Paolo Bonzini wrote:
Il lun 17 giu 2024, 10:59 Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> ha scritto:
>qdev_define_type!(c"test-device", TestDevice);
>impl ObjectImpl for TestDevice {}
>impl DeviceImpl for TestDevice {}
>
>fn main() {
>let d =
Il lun 17 giu 2024, 10:59 Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> ha scritto:
> >qdev_define_type!(c"test-device", TestDevice);
> >impl ObjectImpl for TestDevice {}
> >impl DeviceImpl for TestDevice {}
> >
> >fn main() {
> >let d = TestDevice::new();
> >d.cold_reset();
> >}
On Fri, 14 Jun 2024 20:50, Paolo Bonzini wrote:
On Fri, Jun 14, 2024 at 9:04 AM Manos Pitsidianakis
wrote:
On Thu, 13 Jun 2024 23:57, Paolo Bonzini wrote:
>On Thu, Jun 13, 2024 at 11:16 AM Daniel P. Berrangé
wrote:
>> I guess there's a balance to be had somewhere on the spectrum between
On Fri, Jun 14, 2024 at 9:04 AM Manos Pitsidianakis
wrote:
>
> On Thu, 13 Jun 2024 23:57, Paolo Bonzini wrote:
> >On Thu, Jun 13, 2024 at 11:16 AM Daniel P. Berrangé
> >wrote:
> >> I guess there's a balance to be had somewhere on the spectrum between doing
> >> everything against the raw C
On Thu, 13 Jun 2024 23:57, Paolo Bonzini wrote:
On Thu, Jun 13, 2024 at 11:16 AM Daniel P. Berrangé wrote:
I guess there's a balance to be had somewhere on the spectrum between doing
everything against the raw C binding, vs everything against a perfectly
idiomatic Rust API wrapping the C
On Thu, Jun 13, 2024 at 11:16 AM Daniel P. Berrangé wrote:
> I guess there's a balance to be had somewhere on the spectrum between doing
> everything against the raw C binding, vs everything against a perfectly
> idiomatic Rust API wrapping the C bniding. The latter might be the ideal,
> but from
On Thu, Jun 13, 2024 at 6:06 PM Zhao Liu wrote:
> I think deeper and higher level bindings will have more opens and will
> likely require more discussion and exploration. So could we explore this
> direction on another reference Rust device?
>
> I also think there won’t be too many Rust devices
Hi Paolo,
On Thu, Jun 13, 2024 at 09:56:39AM +0200, Paolo Bonzini wrote:
> Date: Thu, 13 Jun 2024 09:56:39 +0200
> From: Paolo Bonzini
> Subject: Re: [RFC PATCH v2 3/5] rust: add PL011 device model
>
> Il gio 13 giu 2024, 09:13 Daniel P. Berrangé ha
> scritto:
>
> >
On Thu, Jun 13, 2024 at 11:59:12AM +0300, Manos Pitsidianakis wrote:
> On Thu, 13 Jun 2024 11:53, "Daniel P. Berrangé" wrote:
> > On Thu, Jun 13, 2024 at 11:41:38AM +0300, Manos Pitsidianakis wrote:
> > > > > diff --git a/rust/rustfmt.toml b/rust/rustfmt.toml
> > > > > new file mode 100644
> > >
On Thu, Jun 13, 2024 at 09:56:39AM +0200, Paolo Bonzini wrote:
> Il gio 13 giu 2024, 09:13 Daniel P. Berrangé ha
> scritto:
>
> > On Wed, Jun 12, 2024 at 11:27:04PM +0200, Paolo Bonzini wrote:
> > > Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
> > > manos.pitsidiana...@linaro.org> ha scritto:
On Thu, 13 Jun 2024 11:53, "Daniel P. Berrangé" wrote:
On Thu, Jun 13, 2024 at 11:41:38AM +0300, Manos Pitsidianakis wrote:
> > diff --git a/rust/rustfmt.toml b/rust/rustfmt.toml
> > new file mode 100644
> > index 00..ebecb99fe0
> > --- /dev/null
> > +++ b/rust/rustfmt.toml
> > @@ -0,0
On Thu, 13 Jun 2024 10:56, Paolo Bonzini wrote:
Il gio 13 giu 2024, 09:13 Daniel P. Berrangé ha
scritto:
On Wed, Jun 12, 2024 at 11:27:04PM +0200, Paolo Bonzini wrote:
> Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
> manos.pitsidiana...@linaro.org> ha scritto:
>
> > In any case, it is out
On Thu, Jun 13, 2024 at 11:41:38AM +0300, Manos Pitsidianakis wrote:
> > > diff --git a/rust/rustfmt.toml b/rust/rustfmt.toml
> > > new file mode 100644
> > > index 00..ebecb99fe0
> > > --- /dev/null
> > > +++ b/rust/rustfmt.toml
> > > @@ -0,0 +1,7 @@
> > > +edition = "2021"
> > >
Hello Zhao :)
On Thu, 13 Jun 2024 11:30, Zhao Liu wrote:
On Tue, Jun 11, 2024 at 01:33:32PM +0300, Manos Pitsidianakis wrote:
Date: Tue, 11 Jun 2024 13:33:32 +0300
From: Manos Pitsidianakis
Subject: [RFC PATCH v2 3/5] rust: add PL011 device model
X-Mailer: git-send-email 2.44.0
This commit
On Tue, Jun 11, 2024 at 01:33:32PM +0300, Manos Pitsidianakis wrote:
> Date: Tue, 11 Jun 2024 13:33:32 +0300
> From: Manos Pitsidianakis
> Subject: [RFC PATCH v2 3/5] rust: add PL011 device model
> X-Mailer: git-send-email 2.44.0
>
> This commit adds a re-implementation
Il gio 13 giu 2024, 09:13 Daniel P. Berrangé ha
scritto:
> On Wed, Jun 12, 2024 at 11:27:04PM +0200, Paolo Bonzini wrote:
> > Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
> > manos.pitsidiana...@linaro.org> ha scritto:
> >
> > > In any case, it is out of scope for this RFC. Introducing
On Wed, Jun 12, 2024 at 11:27:04PM +0200, Paolo Bonzini wrote:
> Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
> manos.pitsidiana...@linaro.org> ha scritto:
>
> > In any case, it is out of scope for this RFC. Introducing wrappers would
> > be a gradual process.
> >
>
> Sure, how would you feel
Good morning Paolo,
On Thu, 13 Jun 2024 00:27, Paolo Bonzini wrote:
Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> ha scritto:
In any case, it is out of scope for this RFC. Introducing wrappers
would be a gradual process.
Sure, how would you feel about
Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> ha scritto:
> In any case, it is out of scope for this RFC. Introducing wrappers would
> be a gradual process.
>
Sure, how would you feel about such bindings being developed on list, and
maintained in a (somewhat)
On Wed, 12 Jun 2024 19:06, "Daniel P. Berrangé" wrote:
On Wed, Jun 12, 2024 at 05:14:56PM +0300, Manos Pitsidianakis wrote:
On Wed, 12 Jun 2024 15:29, Paolo Bonzini wrote:
> I think this is extremely useful to show where we could go in the task
> of creating more idiomatic bindings.
>
> On
On Wed, Jun 12, 2024 at 05:14:56PM +0300, Manos Pitsidianakis wrote:
> On Wed, 12 Jun 2024 15:29, Paolo Bonzini wrote:
> > I think this is extremely useful to show where we could go in the task
> > of creating more idiomatic bindings.
> >
> > On Tue, Jun 11, 2024 at 12:34 PM Manos Pitsidianakis
On Wed, Jun 12, 2024 at 4:42 PM Manos Pitsidianakis
wrote:
> There was consensus in the community call that we won't be writing Rust
> APIs for internal C QEMU interfaces; or at least, that's not the goal
I disagree with that. We need _some_ kind of bindings, otherwise we
have too much unsafe
On Wed, 12 Jun 2024 15:29, Paolo Bonzini wrote:
I think this is extremely useful to show where we could go in the task
of creating more idiomatic bindings.
On Tue, Jun 11, 2024 at 12:34 PM Manos Pitsidianakis
wrote:
+fn main() {
+println!("cargo::rerun-if-env-changed=MESON_BUILD_DIR");
+
I think this is extremely useful to show where we could go in the task
of creating more idiomatic bindings.
On Tue, Jun 11, 2024 at 12:34 PM Manos Pitsidianakis
wrote:
> +fn main() {
> +println!("cargo::rerun-if-env-changed=MESON_BUILD_DIR");
> +
This commit adds a re-implementation of hw/char/pl011.c in Rust.
It uses generated Rust bindings (produced by `ninja
aarch64-softmmu-generated.rs`) to
register itself as a QOM type/class.
How to build:
1. Make sure rust, cargo and bindgen (cargo install bindgen-cli) are
installed
2.
40 matches
Mail list logo
