All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: kvm@vger.kernel.org, "Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind
Date: Tue, 8 Jun 2021 15:16:51 +0200	[thread overview]
Message-ID: <YL9twy33JvsaeWt7@kroah.com> (raw)
In-Reply-To: <20210608123023.GA1002214@nvidia.com>

On Tue, Jun 08, 2021 at 09:30:23AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 08, 2021 at 08:47:19AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 07, 2021 at 09:55:45PM -0300, Jason Gunthorpe wrote:
> > > Currently really_probe() returns 1 on success and 0 if the probe() call
> > > fails. This return code arrangement is designed to be useful for
> > > __device_attach_driver() which is walking the device list and trying every
> > > driver. 0 means to keep trying.
> > > 
> > > However, it is not useful for the other places that call through to
> > > really_probe() that do actually want to see the probe() return code.
> > > 
> > > For instance bind_store() would be better to return the actual error code
> > > from the driver's probe method, not discarding it and returning -ENODEV.
> > 
> > Why does that matter?  Why does it need to know this?
> 
> Proper return code to userspace are important. Knowing why the driver
> probe() fails is certainly helpful for debugging. Is there are reason
> to hide them? I think this is an improvement for sysfs bind.
> 
> Why this series needs it is because mdev has fixed sys uAPI at this point
> that requires carring the return code from device driver probe() to
> a mdev sysfs function.

What is mdev and what userspace tool requires such a userspace api to
depend on this?

Tools doing manual bind/unbind from userspace are crazy, it's always
been a "look at this neat hack!" type of thing.  To do it "right" you
should always do it correctly within the kernel.

> > > +enum {
> > > +	/* Set on output if the -ERR has come from a probe() function */
> > > +	PROBEF_DRV_FAILED = 1 << 0,
> > > +};
> > > +
> > > +static int really_probe(struct device *dev, struct device_driver *drv,
> > > +			unsigned int *flags)
> > 
> > Ugh, no, please no functions with random "flags" in them, that way lies
> > madness and unmaintainable code for decades to come.
> 
> The alternative to this something like this:
> 
> static int really_probe(struct device *dev, struct device_driver *drv,
> 			int *probe_err)
> 
> And since we still need the 'do not probe defer' in next patches then
> it would have to be this:
> 
> static int really_probe(struct device *dev, struct device_driver *drv,
> 			int *probe_err, bool allow_probe_defer)
> 
> And the two new arguments flowed up through several function call
> sites.
> 
> Do you prefer one of these more?

Random boolean flags as parameters are just as bad.

Make the functions able to be understood when read.

> For your other question PROBEF_ means 'probe flag'.

That was not obvious at all, and not something I would remember the next
time I have to look at this code...

Please use full words, we don't have a limit on restricted characters
anymore, this isn't the 1980's...

thanks,

greg k-h

  reply	other threads:[~2021-06-08 13:16 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08  0:55 [PATCH 00/10] Allow mdev drivers to directly create the vfio_device Jason Gunthorpe
2021-06-08  0:55 ` [Intel-gfx] " Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 01/10] driver core: Do not continue searching for drivers if deferred probe is used Jason Gunthorpe
2021-06-08  5:51   ` Christoph Hellwig
2021-06-08  6:44   ` Greg Kroah-Hartman
2021-06-08 12:16     ` Jason Gunthorpe
2021-06-08 13:13       ` Greg Kroah-Hartman
2021-06-08 13:53         ` Jason Gunthorpe
2021-06-08  7:35   ` Greg Kroah-Hartman
2021-06-08 12:17     ` Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 02/10] driver core: Pull required checks into driver_probe_device() Jason Gunthorpe
2021-06-08  5:59   ` Christoph Hellwig
2021-06-08 12:21     ` Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind Jason Gunthorpe
2021-06-08  6:07   ` Christoph Hellwig
2021-06-08 23:53     ` Jason Gunthorpe
2021-06-08  6:47   ` Greg Kroah-Hartman
2021-06-08 12:30     ` Jason Gunthorpe
2021-06-08 13:16       ` Greg Kroah-Hartman [this message]
2021-06-08 14:03         ` Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 04/10] driver core: Don't return EPROBE_DEFER to userspace during " Jason Gunthorpe
2021-06-08  6:14   ` Christoph Hellwig
2021-06-08  7:37   ` Greg Kroah-Hartman
2021-06-08  0:55 ` [PATCH 05/10] driver core: Export device_driver_attach() Jason Gunthorpe
2021-06-08  6:19   ` Christoph Hellwig
2021-06-08 12:33     ` Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE Jason Gunthorpe
2021-06-08  0:55   ` [Intel-gfx] " Jason Gunthorpe
2021-06-08  6:20   ` Christoph Hellwig
2021-06-08  6:20     ` [Intel-gfx] " Christoph Hellwig
2021-06-11 12:40   ` Cornelia Huck
2021-06-11 12:40     ` [Intel-gfx] " Cornelia Huck
2021-06-14 12:35     ` Jason Gunthorpe
2021-06-14 12:35       ` [Intel-gfx] " Jason Gunthorpe
2021-06-14 12:35       ` Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 07/10] vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind Jason Gunthorpe
2021-06-08  6:21   ` Christoph Hellwig
2021-06-08  0:55 ` [PATCH 08/10] vfio/mtty: Convert to use vfio_register_group_dev() Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 09/10] vfio/mdpy: " Jason Gunthorpe
2021-06-08  0:55 ` [PATCH 10/10] vfio/mbochs: " Jason Gunthorpe
2021-06-08  6:22 ` [PATCH 00/10] Allow mdev drivers to directly create the vfio_device Christoph Hellwig
2021-06-08  6:22   ` [Intel-gfx] " Christoph Hellwig
2021-06-14 14:34 ` Kirti Wankhede
2021-06-14 14:34   ` [Intel-gfx] " Kirti Wankhede
2021-06-14 14:34   ` Kirti Wankhede
2021-06-14 14:36   ` Jason Gunthorpe
2021-06-14 14:36     ` [Intel-gfx] " Jason Gunthorpe
2021-06-14 14:36     ` Jason Gunthorpe
2021-06-14 15:08 Allow mdev drivers to directly create the vfio_device (v2 / alternative) Christoph Hellwig
2021-06-14 15:08 ` [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind Christoph Hellwig
2021-06-15  5:18   ` Greg Kroah-Hartman
2021-06-15  5:18     ` Greg Kroah-Hartman
2021-06-15 10:31   ` Cornelia Huck
2021-06-15 10:31     ` Cornelia Huck
2021-06-15 13:35 Allow mdev drivers to directly create the vfio_device (v3) Christoph Hellwig
2021-06-15 13:35 ` [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind Christoph Hellwig
2021-06-17 14:22 Allow mdev drivers to directly create the vfio_device (v4) Christoph Hellwig
2021-06-17 14:22 ` [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind Christoph Hellwig

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=YL9twy33JvsaeWt7@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --subject='Re: [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.