Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp136778ybh; Mon, 20 Jul 2020 12:20:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQDQW2dnQljQKFov/OiOPDfwQ6yLvyx6lqPH8a2+hKeA/PzTZmtmeed114C/po/7X5nrGY X-Received: by 2002:a17:906:2714:: with SMTP id z20mr23126113ejc.469.1595272802796; Mon, 20 Jul 2020 12:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595272802; cv=none; d=google.com; s=arc-20160816; b=QLHmbREPMfgfkctBTKEp/6MHjR0ea30a8HCpKglRmLwdEAeuuzzJD3EN0Z8gmb+7Jv jy3biD4hb3bGJRrPf9f/gC1H33JKYj8wd3gcOtiZn47cGvZyemOX4UD1qxs0V57aMN5c 7uDhDzwiL0VmZxA7heV9ZpDqjh44oinKZqo4JF04t2Zmb/XmPwDmcYl2UKkQ3NPjnXnz g51aCiGVVimKLQKv+stZDfK4RhXFTur0QuPCmcOvr/4CrYRdVybb6iLYw7WH9P1mFr0J Lkl/iFNrO9n58q9FaGk3urVfwBw34W6txpEfFOTDSYe5Qys+ZLXU0QDxKUGC4RwD5h8D S3DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=ky6RsI97qMXdd0YrvuUVv8AVcLZeDBuYNtGIEjGmS5w=; b=kU/LqMyJxlis+7PbCueoucN7Fja18UvSkju+sQu9AZ3jDI4JaKUMcEq2JQLJrL91ci 7jVioCKmOfjSLwSuZ3V7M0Vd853KFIlortrua/Y5QH8RMUzNLgrAndKd4/2ONy+KBobk E8iPqLABhc63eJyYXkTjDqBuaCrw2fbC4vRpmFKFGTWjRTvdUJVy8cMqmevuMOtglU1f tIB4TnRaLiNYQahUzrBGWJqxc0bd6jwrtILfLoCF8Gq4nxMMIJsIeP8k5g4htpDvEL2E gdaKWYJn0b4lZ1U/LH/m9rGlUYD00TyEYsmhdgj1C/oAAKJRjLF5QdpnAQYUosoG5XhK byBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="pcYZHK/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ca17si10928919ejb.533.2020.07.20.12.19.40; Mon, 20 Jul 2020 12:20:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="pcYZHK/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729541AbgGTTSy (ORCPT + 99 others); Mon, 20 Jul 2020 15:18:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:39420 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728874AbgGTTSy (ORCPT ); Mon, 20 Jul 2020 15:18:54 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5726C2176B; Mon, 20 Jul 2020 19:18:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595272733; bh=Om8xZs9mcJXOyX/qFodq9Pq+msKkoq6y3fF20Bxe1Lw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pcYZHK/Nzn/xdJPoiofCtqIUj3KqPXi57fGrFg3rG/OyA3Q2vwOj6D/g/s/UE20Ml AYLHIADELU1DDkA08Xf/ijoVazGAaTr+a1s+gRD+W98JlKhjPzcNQq2JDrwOijcAVy LdPRq4BOeg9jsaWpQmL2oM6UCmpmEgqSnK0MDDZ0= Date: Mon, 20 Jul 2020 21:19:03 +0200 From: Greg KH To: "Eads, Gage" Cc: "linux-kernel@vger.kernel.org" , "arnd@arndb.de" , "Karlsson, Magnus" , "Topel, Bjorn" Subject: Re: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver Message-ID: <20200720191903.GD1529125@kroah.com> References: <20200712134331.8169-1-gage.eads@intel.com> <20200712134331.8169-2-gage.eads@intel.com> <20200712155810.GC186665@kroah.com> <20200718064656.GB245355@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 20, 2020 at 07:02:05PM +0000, Eads, Gage wrote: > > > > -----Original Message----- > > From: Greg KH > > Sent: Saturday, July 18, 2020 1:47 AM > > To: Eads, Gage > > Cc: linux-kernel@vger.kernel.org; arnd@arndb.de; Karlsson, Magnus > > ; Topel, Bjorn > > Subject: Re: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver > > > > On Fri, Jul 17, 2020 at 06:18:46PM +0000, Eads, Gage wrote: > > > > > > > > > > -----Original Message----- > > > > From: Greg KH > > > > Sent: Sunday, July 12, 2020 10:58 AM > > > > To: Eads, Gage > > > > Cc: linux-kernel@vger.kernel.org; arnd@arndb.de; Karlsson, Magnus > > > > ; Topel, Bjorn > > > > Subject: Re: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver > > > > > > > > On Sun, Jul 12, 2020 at 08:43:12AM -0500, Gage Eads wrote: > > > > > +static int dlb2_probe(struct pci_dev *pdev, > > > > > + const struct pci_device_id *pdev_id) { > > > > > + struct dlb2_dev *dlb2_dev; > > > > > + int ret; > > > > > + > > > > > + dev_dbg(&pdev->dev, "probe\n"); > > > > > > > > ftrace is your friend. Remove all of your debugging code now, you don't > > need > > > > it anymore, especially for stuff like this where you didn't even need it in > > the > > > > first place :( > > > > > > I'll remove this and other similar dev_dbg() calls. This was an oversight on > > my part. > > > > > > I have other instances that a kprobe can't easily replace, such as printing > > structure contents, that are useful for tracing the usage of the driver. It looks > > like other misc drivers use dev_dbg() similarly -- do you consider this an > > acceptable use of a debug print? > > > > Why can't a kernel tracepoint print a structure? > > I meant the command-line installed kprobes[1], but instrumenting the driver is > certainly an option. We don't require the much lower overhead of a tracepoint, > so I didn't choose it. This driver handles the (performance-insensitive) > device configuration, while the fast-path operations take place in user-space. > > Another reason is the "hardware access library" files use only non-GPL external > symbols, and some tracepoint functions are exported GPL. Though it's probably > feasible to lift that tracing code up into a (GPLv2-only) caller function. Stop going through crazy gyrations for something that your own legal team has told you not to do anymore in the first place. No "hardware access library" files please, that's not how Linux drivers are written. you all know better... > But if tracepoints are the preferred method and/or you think the driver would > benefit, I'll make the change. I don't think you need any of that stuff, now that the code works properly, right? greg k-h