All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Kay Sievers <kay@vrfy.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Milos Vyletel <milos.vyletel@sde.cz>,
	linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org,
	virtualization@lists.linux-foundation.org, mst@redhat.com
Subject: Re: [PATCH] virtio-blk: emit udev event when device is resized
Date: Mon, 25 Feb 2013 22:43:39 +0000	[thread overview]
Message-ID: <20130225224339.GA19153@kroah.com> (raw)
In-Reply-To: <CAPXgP13M_krpPMFoBroYkXc4dUQHsZJDua-jSGby8cQ1Afy-HQ@mail.gmail.com>

On Mon, Feb 25, 2013 at 11:39:52PM +0100, Kay Sievers wrote:
> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH <greg@kroah.com> wrote:
> 
> > Hm, I thought we were frowning apon running binaries from udev rules
> > these days, especially ones that might have big consequences (like
> > resizing a disk image) like this.
> >
> > Kay, am I right?
> 
> We removed most of them from the default setups, yes. But there is
> nothing wrong if people want to ship that in some package or as custom
> rules.
> 
> It looks fine to me, we would just not add such things to the default
> set of of rules these days.
> 
> > We already emit KOBJECT_CHANGE events when block devices change, from
> > within the block core code.  Why is the patch below needed instead of
> > using these events that are already generated?  How are virtio block
> > devices special?
> 
> I think we only do that for dm and md and a couple of special cases
> like loop and read-only settings.

What about when we repartition a block device?  I've seen the events
happen then.

Anyway, if you are ok with this, no objection from my side then Rusty.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Kay Sievers <kay@vrfy.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Milos Vyletel <milos.vyletel@sde.cz>,
	linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org,
	virtualization@lists.linux-foundation.org, mst@redhat.com
Subject: Re: [PATCH] virtio-blk: emit udev event when device is resized
Date: Mon, 25 Feb 2013 14:43:39 -0800	[thread overview]
Message-ID: <20130225224339.GA19153@kroah.com> (raw)
In-Reply-To: <CAPXgP13M_krpPMFoBroYkXc4dUQHsZJDua-jSGby8cQ1Afy-HQ@mail.gmail.com>

On Mon, Feb 25, 2013 at 11:39:52PM +0100, Kay Sievers wrote:
> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH <greg@kroah.com> wrote:
> 
> > Hm, I thought we were frowning apon running binaries from udev rules
> > these days, especially ones that might have big consequences (like
> > resizing a disk image) like this.
> >
> > Kay, am I right?
> 
> We removed most of them from the default setups, yes. But there is
> nothing wrong if people want to ship that in some package or as custom
> rules.
> 
> It looks fine to me, we would just not add such things to the default
> set of of rules these days.
> 
> > We already emit KOBJECT_CHANGE events when block devices change, from
> > within the block core code.  Why is the patch below needed instead of
> > using these events that are already generated?  How are virtio block
> > devices special?
> 
> I think we only do that for dm and md and a couple of special cases
> like loop and read-only settings.

What about when we repartition a block device?  I've seen the events
happen then.

Anyway, if you are ok with this, no objection from my side then Rusty.

thanks,

greg k-h

  reply	other threads:[~2013-02-25 22:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21 19:02 [PATCH] virtio-blk: emit udev event when device is resized Milos Vyletel
2013-02-21 23:44 ` Rusty Russell
2013-02-21 23:44   ` Rusty Russell
2013-02-25 22:12   ` Greg KH
2013-02-25 22:12     ` Greg KH
2013-02-25 22:12     ` Greg KH
2013-02-25 22:39     ` Kay Sievers
2013-02-25 22:39       ` Kay Sievers
2013-02-25 22:43       ` Greg KH [this message]
2013-02-25 22:43         ` Greg KH
2013-02-25 23:04         ` Kay Sievers
2013-02-25 23:04           ` Kay Sievers
2013-02-25 23:04         ` Kay Sievers
2013-02-25 22:43       ` Greg KH
2013-02-25 23:38       ` Milos Vyletel
2013-02-25 23:38         ` Milos Vyletel
2013-02-25 23:38         ` Milos Vyletel
2013-02-25 22:39     ` Kay Sievers
2013-02-25 23:41     ` Milos Vyletel
2013-02-25 23:41       ` Milos Vyletel
2013-02-25 23:41       ` Milos Vyletel
2013-02-27  0:34       ` Rusty Russell
2013-02-27  0:46         ` Rusty Russell
2013-02-27  0:34         ` Rusty Russell
2013-02-27 13:09         ` Milos Vyletel
2013-02-27 13:09         ` Milos Vyletel
2013-02-27 13:09           ` Milos Vyletel
2013-02-25  7:43 ` Asias He
2013-02-25  7:43   ` Asias He
2013-02-25 14:54   ` Milos Vyletel
2013-02-25 14:54     ` Milos Vyletel
2013-02-26  3:09     ` Asias He
2013-02-26  3:09       ` Asias He
2013-02-26 13:05       ` Milos Vyletel
2013-02-26 13:05         ` Milos Vyletel
2013-02-27  0:37 ` Rusty Russell
2013-02-27  0:37   ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2013-02-21 19:02 Milos Vyletel

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=20130225224339.GA19153@kroah.com \
    --to=greg@kroah.com \
    --cc=kay@vrfy.org \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=milos.vyletel@sde.cz \
    --cc=mst@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux-foundation.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 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.