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

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 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 Wed, May 29, 2024 at 09:28:21AM +0900, FUJITA Tomonori wrote: > Hi, > > On Tue, 28 May 2024 14:45:02 +0200 > Greg KH <gregkh at linuxfoundation.org> wrote: > > > On Tue, May 28, 2024 at 02:19:24PM +0200, Danilo Krummrich wrote: > >> However, if you have a driver that needs the firmware abstractions, I would be > >> surprised if there were any

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

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 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

# 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 ---

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

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- generator/rust.ml | 84 ++++++++++++++++++++++++++++++++++++++++++++++- rust/Cargo.toml | 2 ++ 2 files changed, 85 insertions(+), 1 deletion(-) diff --git a/generator/rust.ml b/generator/rust.ml index 83afdfe73..dbe9db010 100644 --- a/generator/rust.ml +++ b/generator/rust.ml @@ -31,4 +31,86 @@ open Events let

Dear Pino, Thank you for your helpful review. I fixed the patch based on your comments. I’ll send it later. > The same also for the various .gitkeep files, as they need to be in the > distribution tarball to ensure the directories exist. Is ’src/bin/.gitkeep’ required in EXTRA_DIST? I think because src/bin/ bindtests.rs is included in EXTRA_DIST, ’src/bin/.gitkeep’ is not required to

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

Implementing extents requires some coordination for the Rust code to call back into libnbdkit; I'm not familiar with Rust enough to do that. But with placeholders for those slots, implementing can_cache/cache is trivial. This improves the situation mentioned in commit 031fae85. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/rust/nbdkit-rust-plugin.pod | 10 ++++++++++

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

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- generator/rust.ml | 13 ++++++++--- run.in | 9 ++++++++ rust/Cargo.lock | 6 +++++ rust/Cargo.toml | 4 +--- rust/tests/010_load.rs | 24 +++++++++++++++++++ rust/tests/020_create.rs | 24 +++++++++++++++++++

> I guess this is a stray debug message? Yes. I'm sorry... > we did *not* check them into git. Really? Does it mean that every time you build the library, Cargo.toml is generated? > The actual test parts of this patch are fine, but you need to spend a > bit of time with ‘git rebase -i’ to move parts of patch 3 into patch 2. Does this mean that the followings should be moved to

Hi Hiroyuki, On Tuesday, 30 July 2019 07:51:37 CEST Hiroyuki Katsura wrote: > This patch includes: > > - Event callback handlers > - Tests related to events(410-430) > --- Would it be possible to split the Handle -> Handle<'a> change in an own small patch? This way it can be documented why it was changed. > +pub fn event_to_string(events: &[guestfs::Event])

On Tue, Jul 30, 2019 at 02:51:37PM +0900, Hiroyuki Katsura wrote: >This patch includes: > >- Event callback handlers >- Tests related to events(410-430) >--- > generator/rust.ml | 38 ++++++- > rust/src/base.rs | 24 +++-- > rust/src/error.rs | 8 +- > rust/src/event.rs | 158

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 |

--- .gitignore | 3 + README | 4 +- TODO | 13 +++ configure.ac | 12 +++ docs/nbdkit-plugin.pod | 6 +- docs/nbdkit.pod | 1 + plugins/rust/Cargo.toml.in | 14 +++ plugins/rust/Makefile.am | 65 ++++++++++++