rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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