Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1853624ybi; Mon, 1 Jul 2019 01:27:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyzn4JqVA3aWJPEPFdhG2M879SQu5ZrofS9c5UTJKqf1J52NeS0MDvFwm79/W3Obdc1vywV X-Received: by 2002:a17:902:169:: with SMTP id 96mr12358392plb.306.1561969643075; Mon, 01 Jul 2019 01:27:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561969643; cv=none; d=google.com; s=arc-20160816; b=IB6DewoGDybAPD2pWD29xE99ZeJXF491P5X1cWc27XBdTgZZ+KrgoTVzhjefRqFwXc ymYLkmPahqzmiMw1FlHixP6+VCl+VoZvzP2F2kzAvZBnlY61o34WIthyPTEeo/SHuUQo l4YUeJhhGF9miikLTU5QSt8hKqu3Bl3r54DyZIjoxqX+BmfUwPlTWO4j35JcXmWultE2 8p6H2NeVLvBMb3zAxA0POiEXPVGbXoZF0rydVFKFD131qERwcy7pnAZmV9OMECZhVcRe zO13tNGVmWd5wxbdV9Mrbc4C5JjRcQ/3WBOiUTO/9HRUG8K9RA+aqsQoqjtFDeiQjJjx gbIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=PWtNuPtnW6FRTQ6+XmzM8WmICaA3psSjtpWSbbJr7bE=; b=D/NG2ryjUiyB/k3mtej+lj6CMhcqB0BON2Bxypzn4kxI7MdquqDb3RAzLu7QeM6SAY /fHLzRnziun061KXEQPkgRjLU17HG9Iy09uUvUvyS8331e4NzrkkTjBjoMzzTjOwbHPU aCkM8Fc8rDOSaPmTmReZWV6Ye5zAJ2DG6qQDgG0chaWGPlOlcYQD+WJchgCrbJt7+OlZ hcXC2bY0f6zHgMz2VflAGC2MxrRtbk1p8piQzmb0yhOmchG9oHCKoiWT6bNB0hH+jjGI 8q0V8ihh27opIy8et9EOsoq0AlG79kOCH0euCHdrkkGt7MVZFtMHniiXmxFVGJRzHW1x 7lKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i198si11116748pfe.228.2019.07.01.01.27.07; Mon, 01 Jul 2019 01:27:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727640AbfGAIKW (ORCPT + 99 others); Mon, 1 Jul 2019 04:10:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37372 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727138AbfGAIKW (ORCPT ); Mon, 1 Jul 2019 04:10:22 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7251C307D90F; Mon, 1 Jul 2019 08:10:21 +0000 (UTC) Received: from gondolin (ovpn-117-220.ams2.redhat.com [10.36.117.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id 808357D580; Mon, 1 Jul 2019 08:10:13 +0000 (UTC) Date: Mon, 1 Jul 2019 10:10:10 +0200 From: Cornelia Huck To: Kirti Wankhede Cc: Alex Williamson , , Subject: Re: [PATCH] mdev: Send uevents around parent device registration Message-ID: <20190701101010.7df050a2.cohuck@redhat.com> In-Reply-To: <107cbedf-6c66-a666-d26a-5842d8c24e83@nvidia.com> References: <156155924767.11505.11457229921502145577.stgit@gimli.home> <1ea5c171-cd42-1c10-966e-1b82a27351d9@nvidia.com> <20190626120551.788fa5ed@x1.home> <20190627102107.3c7715d9.cohuck@redhat.com> <107cbedf-6c66-a666-d26a-5842d8c24e83@nvidia.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Mon, 01 Jul 2019 08:10:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Jun 2019 19:42:32 +0530 Kirti Wankhede wrote: > On 6/27/2019 1:51 PM, Cornelia Huck wrote: > > On Thu, 27 Jun 2019 00:33:59 +0530 > > Kirti Wankhede wrote: > > > >> On 6/26/2019 11:35 PM, Alex Williamson wrote: > >>> On Wed, 26 Jun 2019 23:23:00 +0530 > >>> Kirti Wankhede wrote: > >>> > >>>> On 6/26/2019 7:57 PM, Alex Williamson wrote: > >>>>> This allows udev to trigger rules when a parent device is registered > >>>>> or unregistered from mdev. > >>>>> > >>>>> Signed-off-by: Alex Williamson > >>>>> --- > >>>>> drivers/vfio/mdev/mdev_core.c | 10 ++++++++-- > >>>>> 1 file changed, 8 insertions(+), 2 deletions(-) > >>>>> > >>>>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c > >>>>> index ae23151442cb..ecec2a3b13cb 100644 > >>>>> --- a/drivers/vfio/mdev/mdev_core.c > >>>>> +++ b/drivers/vfio/mdev/mdev_core.c > >>>>> @@ -146,6 +146,8 @@ int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops) > >>>>> { > >>>>> int ret; > >>>>> struct mdev_parent *parent; > >>>>> + char *env_string = "MDEV_STATE=registered"; > >>>>> + char *envp[] = { env_string, NULL }; > >>>>> > >>>>> /* check for mandatory ops */ > >>>>> if (!ops || !ops->create || !ops->remove || !ops->supported_type_groups) > >>>>> @@ -196,7 +198,8 @@ int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops) > >>>>> list_add(&parent->next, &parent_list); > >>>>> mutex_unlock(&parent_list_lock); > >>>>> > >>>>> - dev_info(dev, "MDEV: Registered\n"); > >>>>> + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp); > >>>>> + > >>>> > >>>> Its good to have udev event, but don't remove debug print from dmesg. > >>>> Same for unregister. > >>> > >>> Who consumes these? They seem noisy. Thanks, > >>> > >> > >> I don't think its noisy, its more of logging purpose. This is seen in > >> kernel log only when physical device is registered to mdev. > > > > Yes; but why do you want to log success? If you need to log it > > somewhere, wouldn't a trace event be a much better choice? > > > > Trace events are not always collected in production environment, there > kernel log helps. I'm with you for *errors*, but I'm not sure you should rely on *success* messages, though. If you want to be able to figure out the sequence of registering etc. in all cases, I think it makes more sense to invest in an infrastructure like tracing and make sure that is it turned on for any system that matters.