All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	linux-kernel@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH 31/34] move virtrng_remove to .devexit.text
Date: Thu, 1 Oct 2009 14:32:13 +0200	[thread overview]
Message-ID: <20091001123213.GL5718@redhat.com> (raw)
In-Reply-To: <20091001101727.GC6386@pengutronix.de>

On Thu, Oct 01, 2009 at 12:17:27PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Thu, Oct 01, 2009 at 11:45:18AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Oct 01, 2009 at 11:31:06AM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > > 
> > > On Thu, Oct 01, 2009 at 11:12:18AM +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Oct 01, 2009 at 10:44:48AM +0200, Christian Borntraeger wrote:
> > > > > Am Donnerstag 01 Oktober 2009 10:28:35 schrieb Uwe Kleine-König:
> > > > > > The function virtrng_remove is used only wrapped by __devexit_p so define
> > > > > > it using __devexit.
> > > > > > 
> > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > > > > Acked-by: Sam Ravnborg <sam@ravnborg.org>
> > > > > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > > Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> > > > > 
> > > > > Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > > > 
> > > > FWIW
> > > > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> > > ok
> > > 
> > > > > It seems that there are similar changes possible in other virtio drivers (e.g. 
> > > > > virtio_net). 
> > > http://thread.gmane.org/gmane.linux.kernel/896297/focus=896309
> > > 
> > > > Yes, and more importantly drivers/virtio/virtio.c as well.
> > > Hm, I don't see it:
> > > 
> > > 	$ git grep -E '__(dev)?exit_p' linus/master:drivers/virtio/virtio.c
> > > 
> > > 	$
> > > 
> > > Well, you could add something, but adding __devexit is a noop for most
> > > kernels.  It matters only if you don't have CONFIG_HOTPLUG.
> > 
> > And MODULE.
> Well, discarding does not really depend on CONFIG_MODULE.
> .devexit sections are only discarded from vmlinux (and not modules) and
> only if CONFIG_HOTPLUG=n.  So my statement could be extended to:
> 
> Adding __devexit is a noop for most kernels. It matters only if you
> don't have CONFIG_HOTPLUG and then only for code that is not compiled as
> a module.
> 
> > > In this series I only addressed drivers that use __{,dev}exit and
> > > __{,dev}exit_p inconsistenly.  I.e. my script greps for __{,dev}exit_p
> > > and checks the prototype of the wrapped function.  I have another
> > > script that does a similar check for platform_devices in general.  This
> > > one also notices if you have a __devexit function that isn't wrapped by
> > > __devexit_p.
> > 
> > Can we teach sparse about this?
> I don't know much about sparse, better ask on linux-sparse.
>  
> > > So if you want to see drivers/virtio/virtio.c improving, send patches
> > > yourself :-)
> > 
> > Here's my reasoning:
> > include/linux/virtio.h defines virtio_driver, and remove pointer
> > there is only used on hot-unplug or module removal.
> > This is the only reason I see that we can make device removal as devexit.
> > So we can make all of them devexit then?
> Exactly the same applies to platform_drivers.  The remove callback is
> only called if the driver is unregistered or the device is unbound.
> 
> But note it's not an error in general to use a .text function as remove
> callback.  E.g. take drivers/gpio/twl4030-gpio.c.  gpio_twl4030_remove
> is used in gpio_twl4030_probe which is defined using __devinit.  So
> using __devexit for gpio_twl4030_remove is wrong.  (So there is a bug,
> as gpio_twl4030_remove uses __devexit.)  I didn't try, but as far as I
> understand this will result in a compile error if the driver is built-in
> with HOTPLUG=n.

Wait a second.
As far as I understand, __devexit makes it possible to remove code if
hotplug is off.

At least for static functions, it's enough to mark their only use
as _devexit_p, and compiler will remove the text as it's unused.

Isn't that right?

If so, what, again, was the motivation for the patches that added
__devexit to functions that were already used with __devexit_p?


> Best regards
> Uwe
> 
> -- 
> Pengutronix e.K.                              | Uwe Kleine-König            |
> Industrial Linux Solutions                    | http://www.pengutronix.de/  |

  reply	other threads:[~2009-10-01 12:35 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-01  8:26 [PATCH 00/35] fix usage of __{,dev}exit_p Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 01/34] move asic3_remove to .devexit.text Uwe Kleine-König
2009-10-01 17:30   ` Samuel Ortiz
2009-10-01  8:28 ` [PATCH 02/34] move atp870u_remove " Uwe Kleine-König
2009-10-01 14:20   ` James Bottomley
2009-10-01 14:20     ` James Bottomley
2009-10-02 19:13     ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 03/34] move bbc_remove " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 04/34] don't use __devexit_p to wrap excite_nand_remove Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 05/34] move grover_remove to .devexit.text Uwe Kleine-König
2009-10-06  5:05   ` Dmitry Torokhov
2009-10-01  8:28 ` [PATCH 06/34] don't use __devexit_p to wrap hal2_remove Uwe Kleine-König
2009-10-01  8:36   ` Takashi Iwai
2009-10-01  8:36     ` Takashi Iwai
2009-10-01  8:53     ` Uwe Kleine-König
2009-10-02  9:02       ` Takashi Iwai
2009-10-02  9:02         ` Takashi Iwai
2009-10-02  9:20         ` Uwe Kleine-König
2009-10-02  9:42           ` Takashi Iwai
2009-10-02  9:42             ` Takashi Iwai
2009-10-01  8:28 ` [PATCH 07/34] move ilo_remove to .devexit.text Uwe Kleine-König
2009-10-01 14:10   ` Altobelli, David
2009-10-01 17:44     ` Uwe Kleine-König
2009-10-01 17:49       ` Altobelli, David
2009-10-01  8:28 ` [PATCH 08/34] move initio_remove_one " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 09/34] don't use __devexit_p to wrap iodev_remove Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 10/34] don't use __devexit_p to wrap lasi700_driver_remove Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 11/34] move mcf_remove to .devexit.text Uwe Kleine-König
2009-10-02  0:53   ` Greg Ungerer
2009-10-01  8:28 ` [PATCH 12/34] move megaraid_detach_one " Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 13/34] don't use __devexit_p to wrap meth_remove Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 14/34] don't wrap mlx4_remove_one in __devexit_p Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 15/34] move mpc85xx_pci_err_remove to .devexit.text Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 16/34] move mv64x60_pci_err_remove " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 17/34] move mxcnd_remove to .exit.text Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 18/34] don't use __devexit_p to wrap NCR_Q720_remove Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 19/34] move s3c_adc_remove to .devexit.text Uwe Kleine-König
2009-10-02  7:20   ` Ben Dooks
2009-10-01  8:28 ` [PATCH 20/34] move s3c_pwm_remove " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 21/34] wrap sc26xx_driver_remove by __exit_p Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 22/34] don't use __devexit_p to wrap sgiseeq_remove Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 23/34] don't use __devexit_p to wrap sgiwd93_remove Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 24/34] don't use __devexit_p to wrap snd_sgio2audio_remove Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 25/34] don't use __devexit_p to wrap snirm710_driver_remove Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 26/34] move spidev_remove to .devexit.text Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 27/34] move stex_remove " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 28/34] move vhci_hcd_remove " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 29/34] move virtballoon_remove " Uwe Kleine-König
2009-10-01  9:35   ` Michael S. Tsirkin
2009-10-01  9:52     ` Uwe Kleine-König
2009-10-01 10:07       ` Michael S. Tsirkin
2009-10-06  9:47   ` Rusty Russell
2009-10-01  8:28 ` [PATCH 30/34] move virtnet_remove " Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 31/34] move virtrng_remove " Uwe Kleine-König
2009-10-01  8:44   ` Christian Borntraeger
2009-10-01  8:48     ` Uwe Kleine-König
2009-10-01  9:12     ` Michael S. Tsirkin
2009-10-01  9:31       ` Uwe Kleine-König
2009-10-01  9:45         ` Michael S. Tsirkin
2009-10-01 10:17           ` Uwe Kleine-König
2009-10-01 12:32             ` Michael S. Tsirkin [this message]
2009-10-01 17:41               ` Uwe Kleine-König
2009-10-01 18:05                 ` Michael S. Tsirkin
2009-10-01 18:19                   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 32/34] don't use __devexit_p to wrap zalon_remove Uwe Kleine-König
2009-10-01  8:28   ` Uwe Kleine-König
2009-10-01  8:28 ` [PATCH 33/34] move lis3l02dq_remove to .devexit.text Uwe Kleine-König
2009-10-01  9:38   ` Jonathan Cameron
2009-10-01  8:28 ` [PATCH 34/34] move sca3000_remove " Uwe Kleine-König
2009-10-01  9:39   ` Jonathan Cameron

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=20091001123213.GL5718@redhat.com \
    --to=mst@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sam@ravnborg.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 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.