Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7395115imu; Tue, 22 Jan 2019 05:27:25 -0800 (PST) X-Google-Smtp-Source: ALg8bN5c7/ANjSMf34o6dmeOaTxDUoQYH6+FQAxLUend5gNv8D5LOLl2If4m/jsjnDiSoumkz+bf X-Received: by 2002:a17:902:981:: with SMTP id 1mr33404645pln.142.1548163645199; Tue, 22 Jan 2019 05:27:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548163645; cv=none; d=google.com; s=arc-20160816; b=w5z2rwM5GrGX8a9plHp4Ch4OJMKxZfpGcr0lyqCyXmxtYQmkzHtrrR7g4YWPgO86Wf 8Dlm3Z34mLxdp8Ufo6q2NAH01bdusGoJkWSMl4OcLYsoIP19D6muGLcFET9VYcMSNVb4 aNXVnDzGzKbm8eSJ7MsSNrSWCZLd1xLD3Z1uRpxOxl52J2RFE6GpNF2Z8a+p6J+6P0cI U20PUYeRP2ycBAegVdbfKceR2F4W7n016FGnEuHpYg8SZ8wTOjSN6F2ziRpUUNM7U4al diqf1+HnIDt8S2GapqYwXe4Z5NHcZzz552Oiut5jbD5S51NKOMVuNMY+yT4lmfEx3R+R 9lAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=GRc+EmacuPtXfhscFtt/+Dg99jWb8jWP5zEt13HRmhw=; b=ACfTbCaXeXcrZPiHTSazziZtlP1dm0PozYeiwMwMf5GEwuLJd9SxMH/W38QQQK8C0M tQ0ktsKozP6WlwrQZeJRvwKA8fqfuA5zhYVYnarQUERvtW1MqBPCqEWUBVu40jrWG+pr SclEFA4XVIwIN5N5l3z/4E0ieXW8cTFHcxH+puR1cz7kCkS6ZORaMQc4mv3jI5U0k0IP KZwQUCYG6ARPwSjfrH2u8uVimE5VOCtd2I0pFvyc/VnVn0oQ7w/Bq9K0gUs0/wedd1La bbARe7lJAVpf62gkV7SWyibRv69d+lr5zGnXLorGicu6BOcfEQPNDwqRy9AvlehhGBBn MCeQ== 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=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j14si16896996pgg.44.2019.01.22.05.27.09; Tue, 22 Jan 2019 05:27:25 -0800 (PST) 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=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728439AbfAVNZx (ORCPT + 99 others); Tue, 22 Jan 2019 08:25:53 -0500 Received: from 8bytes.org ([81.169.241.247]:58826 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727936AbfAVNZx (ORCPT ); Tue, 22 Jan 2019 08:25:53 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id 1C2AE53D; Tue, 22 Jan 2019 14:25:52 +0100 (CET) Date: Tue, 22 Jan 2019 14:25:51 +0100 From: Joerg Roedel To: Christoph Hellwig Cc: Robin Murphy , Corentin Labbe , m.szyprowski@samsung.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dma-debug: add dumping facility via debugfs Message-ID: <20190122132551.GC32526@8bytes.org> References: <1547646265-9414-1-git-send-email-clabbe@baylibre.com> <2f43688f-9c08-a9c4-6175-caa3d2e40261@arm.com> <20190118113543.GA9481@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190118113543.GA9481@lst.de> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 18, 2019 at 12:35:43PM +0100, Christoph Hellwig wrote: > On Wed, Jan 16, 2019 at 06:10:13PM +0000, Robin Murphy wrote: > > It's a shame that this is pretty much a duplication of > > debug_dma_dump_mappings(), but there seems no straightforward way to define > > one in terms of the other :/ > > We could always play some macro magic, but I think that is worse than > duplicating a little bit of functionality. I havn't checked in detail, can seq_buf be used somehow to write a function that fits both cases? > Btw, the dev argument to debug_dma_dump_mappings is always NULL and > could be removed.. This function was also written as a debug-helper for driver developers. As such it might not make it into the final driver, but the developer might want to use it to dump the mappings for her device only. So I'd like to keep the parameter, even when it is always NULL for in-kernel uses. > > (although given that we'd rather not have that weird external interface > > anyway, maybe "now you can use debugfs instead" might be justification > > enough for cleaning it up...) > > One argument against that is the system might be in a shape where you > can't easily read a file when it is in that shape. The argument for > that is that in many systems the full list of mappings might overwhelm > the kernel log. For driver developers a file is easier to use, but in case of an unusable system one can at least easily read out parts of the dma-mappings from a crash-dump if it is in the kernel-log. So I think it makes sense to have both. Regards, Joerg