similar to: [RFC PATCH 7/8] rust: add firmware abstractions

On Thu, May 30, 2024 at 08:28:24AM +0900, FUJITA Tomonori wrote: > Hi, > > On Wed, 29 May 2024 21:57:03 +0200 > Greg KH <gregkh at linuxfoundation.org> wrote: > > >> For a Rust PHY driver, you know that you have a valid pointer to C's > >> device object of C's PHY device during the probe callback. The driver > >> creates a Rust device

On Thu, May 30, 2024 at 01:24:33PM +0900, FUJITA Tomonori wrote: > Hi, > > On Thu, 30 May 2024 04:01:39 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > > > On Thu, May 30, 2024 at 08:28:24AM +0900, FUJITA Tomonori wrote: > >> Hi, > >> > >> On Wed, 29 May 2024 21:57:03 +0200 > >> Greg KH <gregkh at linuxfoundation.org>

On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote: > Hi, > > On Fri, 31 May 2024 11:59:47 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > > > Once we get to a conclusion I can send a series with only the device and firmare > > abstractions such that we can get them in outside of the scope of the reset of > > both series to get your

On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote: > Hi, > > On Fri, 31 May 2024 11:59:47 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > > > Once we get to a conclusion I can send a series with only the device and firmare > > abstractions such that we can get them in outside of the scope of the reset of > > both series to get your

On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote: > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > > Anyway, that's all hand-wavy right now, sorry, to get back to the point > > here, again, let's take this, which will allow the firmware bindings to > > be resubmitted and hopefully accepted, and we can move forward from > > there to

On Sat, Jun 8, 2024 at 11:16?PM Asahi Lina <lina at asahilina.net> wrote: > > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina <lina at asahilina.net> > >> > >> Add abstractions for DRM drivers and devices. These go together in one > >> commit

Implement the DRM driver abstractions. The `Driver` trait provides the interface to the actual driver to fill in the driver specific data, such as the `DriverInfo`, driver features and IOCTLs. Co-developed-by: Asahi Lina <lina at asahilina.net> Signed-off-by: Asahi Lina <lina at asahilina.net> Signed-off-by: Danilo Krummrich <dakr at redhat.com> ---

Hi Lina, Welcome back! On Sun, Jun 09, 2024 at 02:15:57PM +0900, Asahi Lina wrote: > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina <lina at asahilina.net> > > This is missing an entry for DRIVER_GEM_GPUVA. And some others perhaps. > > I suppose some are legacy

On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > Anyway, that's all hand-wavy right now, sorry, to get back to the point > here, again, let's take this, which will allow the firmware bindings to > be resubmitted and hopefully accepted, and we can move forward from > there to "real" things like a USB or PCI or even platform device and > driver binding

On Wed, Jun 19, 2024 at 01:31:39AM +0200, Danilo Krummrich wrote: > Implement the DRM driver abstractions. > > The `Driver` trait provides the interface to the actual driver to fill > in the driver specific data, such as the `DriverInfo`, driver features > and IOCTLs. > > Co-developed-by: Asahi Lina <lina at asahilina.net> > Signed-off-by: Asahi Lina <lina at

We do not promise API stability for non-C languages; this is an API break as follows: instead of calling plugin_init with a static model, you can now populate .thread_model in the Plugin struct, with a default to Parallel. As in C, the model is still chosen at .load time (at most, making it a function allows you to alter it based on configuration), and not something that can change

Without clarifying handle's lifetime, it is unable to see how long the callbacks which the handle owns will live. Then, Rust compiler will infer that the callbacks have 'static lifetime. It is not convenient for users. --- generator/rust.ml | 38 ++++++++++++++++++++++++++++++- rust/src/base.rs | 23 +++++++++++++------ rust/src/error.rs |

Hi, I'm now implementing generators of Rust, and I faced a problem. In order for the wrapper to 'understand' the struct passed from C API, it is required to incorporate the definition of the struct in C into Rust code. I have two approaches. 1. Create raw struct(#[repr(C)]), which has the equivalent memory mapping to C struct and access through this struct in Rust 2. Use bindgen to

On Wed, Jun 05, 2019 at 03:33:51PM +0900, Hiroyuki Katsura wrote: > Hi, I'm now implementing generators of Rust, and I faced a problem. > > In order for the wrapper to 'understand' the struct passed from C API, it > is required to incorporate the definition of the struct in C into Rust > code. > > I have two approaches. I don't know a lot about Rust

On Fri, Aug 16, 2019 at 12:08:11PM -0500, Eric Blake wrote: > We do not promise API stability for non-C languages; this is an API > break as follows: instead of calling plugin_init with a static model, > you can now populate .thread_model in the Plugin struct, with a > default to Parallel. As in C, the model is still chosen at .load time > (at most, making it a function allows you

Dear Richard, > We have tended to avoid this in other languages because the results > can be very poor quality (eg. swig bindings are usually terrible). > However if the resulting code from bindgen is high quality and > accurately covers all the features that libguestfs bindings need then > we can consider it. Thank you for your reply. Actually, I have not used bindgen and I

From: Asahi Lina <lina at asahilina.net> DRM drivers need to be able to declare which driver-specific ioctls they support. Add an abstraction implementing the required types and a helper macro to generate the ioctl definition inside the DRM driver. Note that this macro is not usable until further bits of the abstraction are in place (but it will not fail to compile on its own, if not

On Wed, Jul 17, 2019 at 06:49:39PM +0900, Hiroyuki Katsura wrote: >From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > >Rust bindings: Add create / close functions > >Rust bindings: Add 4 bindings tests > >Rust bindings: Add generator of structs > >Rust bindings: Add generator of structs for optional arguments > >Rust bindings: Add generator of

# HG changeset patch # User fujita.tomonori@lab.ntt.co.jp # Node ID 7111077b493ea53ef055ce38098f8af67f87d749 # Parent ed8d345449c176cb5fe0ccff4299da782eb63c08 SCSI frontend and backend drivers'' common Makefile and header Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> diff -r ed8d345449c1 -r 7111077b493e buildconfigs/linux-defconfig_xen0_x86_32 ---

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> Rust bindings: Add create / close functions Rust bindings: Add 4 bindings tests Rust bindings: Add generator of structs Rust bindings: Add generator of structs for optional arguments Rust bindings: Add generator of function signatures Rust bindings: Complete actions Rust bindings: Fix memory management Rust bindings: Add