From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Lyude Paul" <lyude@redhat.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
"Maíra Canal" <mairacanal@riseup.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Zijun Hu" <quic_zijuhu@quicinc.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Alexander Lobakin" <aleksander.lobakin@intel.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [PATCH] WIP: drivers/base: Add virtual_device_create()
Date: Sat, 1 Feb 2025 09:00:00 +0100 [thread overview]
Message-ID: <2025020106-avert-senorita-4181@gregkh> (raw)
In-Reply-To: <Z50ZuzrDn-GQWOuP@cassiopeiae>
On Fri, Jan 31, 2025 at 07:43:07PM +0100, Danilo Krummrich wrote:
> On Fri, Jan 31, 2025 at 05:40:01PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Jan 31, 2025 at 09:00:32AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 30, 2025 at 04:28:26PM -0500, Lyude Paul wrote:
> > > > As Greg KH pointed out, we have a nice /sys/devices/virtual directory free
> > > > for the taking - but the vast majority of device drivers concerned with
> > > > virtual devices do not use this and instead misuse the platform device API.
> > > >
> > > > To fix this, let's start by adding a simple function that can be used for
> > > > creating virtual devices - virtual_device_create().
> > > >
> > > > Signed-off-by: Lyude Paul <lyude@redhat.com>
> > > >
> > > > ---
> > > >
> > > > So, WIP obviously because I wrote this up in a few minutes - but this goes
> > > > off the idea that Danilo suggested to me off-list of coming up with a
> > > > simple API for handling virtual devices that's a little more obvious to
> > > > use. I wanted to get people's feedback and if we're happy with this idea,
> > > > I'm willing to go through and add some pointers to this function in various
> > > > platform API docs - along with porting over the C version of VKMS over to
> > > > this API.
> > >
> > > This is a big better, but not quite. Let me carve out some time today
> > > to knock something a bit nicer together...
> >
> > Ok, here's a rough first-cut. It builds, and boots, and I've converted
> > a driver to use the api to prove it works here. I'll add a bunch more
> > documentation before turning it into a "real" patch, but this should
> > give you something to work off of.
> >
> > I've run out of time for tonight (dinner is calling), but I think you
> > get the idea, right? If you want to knock up a rust binding for this
> > api, it should almost be identical to the platform api you were trying
> > to use before, right?
>
> Yes, additionally, since this can't use the existing platform abstractions any
> more, we need the bus abstraction for the virtual bus, i.e. the corresponding
> driver::RegistrationOps implementation, module_virtual_driver macro, etc. Should
> be a little less than 200 lines of code.
I hope so as the original C code for this is less than 200 lines of code :)
I wonder what it would look like to do a "real" bus in rust, maybe I'll
try that someday, but for now, I want this to be used by C code...
> Other than in C, in Rust we don't need the "artificial" match between a virtual
> device and a virtual driver to have automatic cleanup through things like
> devm_kzalloc().
What artificial match? Ah, you mean they would both be in the same
"object"?
> But I guess we want it for consistency and to have the corresponding sysfs
> entries and uevents. OOC, are there any other reasons?
I don't really understand the objection here. Oooh, you want the C code
to both create/manage the driver AND the device at the same time? Hey I
like that, it would make the interface to it even simpler! Let me go
try that, and see if it is what you are thinking of here...
thanks!
greg k-h
next prev parent reply other threads:[~2025-02-01 8:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 23:49 [PATCH 0/2] rust/kernel: Add bindings for manually creating devices Lyude Paul
2025-01-22 23:49 ` [PATCH 1/2] rust/kernel: Add platform::Device::from_raw() Lyude Paul
2025-01-28 14:35 ` Alice Ryhl
2025-01-22 23:49 ` [PATCH 2/2] rust/kernel: Add platform::ModuleDevice Lyude Paul
2025-01-23 6:23 ` Greg Kroah-Hartman
2025-01-23 10:21 ` Danilo Krummrich
2025-01-23 14:17 ` Greg Kroah-Hartman
2025-01-24 10:52 ` Danilo Krummrich
2025-01-30 21:28 ` [PATCH] WIP: drivers/base: Add virtual_device_create() Lyude Paul
2025-01-30 21:58 ` Lyude Paul
2025-02-01 8:32 ` Greg Kroah-Hartman
2025-01-31 3:34 ` kernel test robot
2025-01-31 8:00 ` Greg Kroah-Hartman
2025-01-31 16:40 ` Greg Kroah-Hartman
2025-01-31 18:43 ` Danilo Krummrich
2025-02-01 8:00 ` Greg Kroah-Hartman [this message]
2025-02-03 9:39 ` [RFC] driver core: add a virtual bus for use when a simple device/bus is needed Greg Kroah-Hartman
2025-02-03 10:02 ` Greg Kroah-Hartman
2025-02-03 11:01 ` Danilo Krummrich
2025-02-03 11:25 ` Greg Kroah-Hartman
2025-02-03 14:33 ` Greg Kroah-Hartman
2025-02-03 15:32 ` Simona Vetter
2025-02-03 15:38 ` Greg Kroah-Hartman
2025-02-03 22:45 ` Lyude Paul
2025-02-03 21:13 ` Danilo Krummrich
2025-02-04 6:05 ` Greg Kroah-Hartman
2025-02-03 9:45 ` [PATCH] WIP: drivers/base: Add virtual_device_create() Simona Vetter
2025-02-03 9:51 ` Greg Kroah-Hartman
2025-01-31 16:42 ` Simona Vetter
2025-01-31 10:43 ` Andy Shevchenko
2025-01-24 0:33 ` [PATCH 2/2] rust/kernel: Add platform::ModuleDevice Lyude Paul
2025-01-24 11:02 ` Danilo Krummrich
2025-01-31 16:41 ` Simona Vetter
2025-01-24 21:19 ` Lyude Paul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025020106-avert-senorita-4181@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=aleksander.lobakin@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dakr@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=lyude@redhat.com \
--cc=mairacanal@riseup.net \
--cc=quic_zijuhu@quicinc.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).