Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932679AbdIFO5k (ORCPT ); Wed, 6 Sep 2017 10:57:40 -0400 Received: from smtp.eu.citrix.com ([185.25.65.24]:29745 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932247AbdIFO5i (ORCPT ); Wed, 6 Sep 2017 10:57:38 -0400 X-IronPort-AV: E=Sophos;i="5.41,484,1498521600"; d="scan'208";a="52341594" Date: Wed, 6 Sep 2017 15:57:10 +0100 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Juergen Gross CC: Vincent Legout , Jan Beulich , , Boris Ostrovsky , Subject: Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device Message-ID: <20170906145710.7o6wmnfxq32z2bgw@dhcp-3-128.uk.xensource.com> References: <20170704114823.pvk6323gfebioikl@bres.gandi.net> <20170704165927.c6dgitftm4v3xk7w@dhcp-3-128.uk.xensource.com> <20170705080804.j6lptyhmjguhdj47@bres.gandi.net> <595CBCB40200007800168A16@prv-mh.provo.novell.com> <20170705123715.exc4qyllpxatxpnj@bres.gandi.net> <595CFD650200007800168BF1@prv-mh.provo.novell.com> <20170705133000.ugnbckhul4xevzk5@bres.gandi.net> <20170707081053.s6pocjgz3ibkkyjg@dhcp-3-128.uk.xensource.com> <20170905072849.mymaugf3im2luqai@bres.gandi.net> <9e39fe02-d1ca-7b72-7bd3-3461b94c618d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9e39fe02-d1ca-7b72-7bd3-3461b94c618d@suse.com> User-Agent: NeoMutt/20170714 (1.8.3) X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1135 Lines: 28 On Wed, Sep 06, 2017 at 12:18:03PM +0200, Juergen Gross wrote: > On 05/09/17 09:28, Vincent Legout wrote: > > Hello, > > > > Sorry for such a long delay. I'm still interested in having this patch > > merged. > > > > I've tried to make the patch more generic and move it to xenbus as > > discussed during the Xen summit, but I'm not sure how or if it's > > possible. Would doing something in xenbus_otherend_changed() make sense? > > But do we have enough information there? I'd be happy to get any advice, > > I've re-attached the original patch. > > Maybe you could add a callback to struct xenbus_driver which is called > by xenbus_otherend_changed() if available and which will return the > missing information (e.g. the kobj). Hello, I'm still unsure we should call KOBJ_OFFLINE, mostly because I don't see any other block devices doing so. AFAICT it seems to be used only by cpu and memory hotplug. Maybe xenbus should use the device_offline function instead on each device it wants to remove? >From my limited Linux bus handling understanding, this seems to be more in line with what ACPI does for example. Thanks, Roger.