Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2824319ybd; Mon, 24 Jun 2019 13:24:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGvgaPEa6gqxbHtG/eqLcQ+zkeMTIhzrkt6dmO3UaAluvm4Y5vXDmb3RmflStAz/7dkE8T X-Received: by 2002:a17:902:54f:: with SMTP id 73mr147260203plf.246.1561407847309; Mon, 24 Jun 2019 13:24:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561407847; cv=none; d=google.com; s=arc-20160816; b=Tq7n0Z3QWiYpFo40eRMulHpXaQ62iUqRjmfpTRyrb498wmLFhzJMIRRh1vV5Rw0452 uXGahWMiqZEURwsR2n+zRormRLubB6MMhzGZWSCfm9Rotf5bl/rnKefbHyd1SvrCBGyf jCBRNwKL5itLzJWltzxZJoHwks2WDtaCCAeADvrb0sH+wI7Myrnpjc/MyvIYZzTFbpqv 4bn1JSbgEkn6/J5+QfpXYAER7f+YFIdV/DsI+BerWVerxmYYmbgk7dBcqIl7Ssm76ylr ZNARcL6+XWbAa2CVWky2Yln9xgLRiKfj86cPNOtj/n2r+xt9UlYvD6vuSayT6+FFqd4g PSxw== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=fY1uicw44jx44qL4fNl32lhk7YJ+D/1JLgTlaHjUDKg=; b=g6Hknz/CrcaPEPsfr7dg7xC6mfS+V2dDGcl9yBy9OOiP2hf0vdbLXTfdqak5z4z9op eenJW2smlsv8QPZGmC6ZnYwQeR1TEq9lgRbeY7ADlHAJ3P8xBobyLxEcZMXIRaPxHv0v FfoXbTqv+mcouNsji3ZNcU/JdUDVfNFflTbBR5QJo9nIADqFS3WCyM0bEG5xbBS/QTAd WMXrGWOnLoc6UcZxwP1GYt2p2jqZgQVK7B5qOpjesHXB5HBtugGloQ/zv1IBxlRgzISN knnxYIJ0q7dRmeY6DsUEj3/g69zj+BbgMZeixZmXknJEXU+xmOovqEgmWBLSXMXaHFYe cJyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="X/gGuMjI"; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s11si10446668pgp.326.2019.06.24.13.23.51; Mon, 24 Jun 2019 13:24:07 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="X/gGuMjI"; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729812AbfFXQi5 (ORCPT + 99 others); Mon, 24 Jun 2019 12:38:57 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:58138 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbfFXQi5 (ORCPT ); Mon, 24 Jun 2019 12:38:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fY1uicw44jx44qL4fNl32lhk7YJ+D/1JLgTlaHjUDKg=; b=X/gGuMjIdfzOOqUQIRE98lBM8 hQJ/bXQjAv+k3udNbi95nJ1/gufdyY5py1gC7U+WAQHzoM0Ln6sIYtbupQ39CQlULhoQ/UyYEb7IG YeXmW2/8XhLDS4FP6sFxS2sB22txPlNU3jpuu/FN1ZppX+4ExMwDh9PBvRxcYBu4c1mt0j0tVV7Vx Xivr/9G0/IY9FiZVWLWYjAMsJGXuMR7FvmzTGXKxbIccY9AIdfr7XJHKnro49rCD2VjXwl1/Xav2O mBIHOWiOZqawA+qOwgPJH3uOZb0nZ1UxM7oafp8dKlXGhqtDAhIOk/AHiwNrlh+JMta0ZdvO7nKD4 VYBICpYzQ==; Received: from 177.205.71.220.dynamic.adsl.gvt.net.br ([177.205.71.220] helo=coco.lan) by bombadil.infradead.org with esmtpsa (Exim 4.92 #3 (Red Hat Linux)) id 1hfRzc-0001LO-7X; Mon, 24 Jun 2019 16:38:56 +0000 Date: Mon, 24 Jun 2019 13:38:52 -0300 From: Mauro Carvalho Chehab To: Jonathan Corbet Cc: linux-doc@vger.kernel.org, Matthew Wilcox , Jani Nikula , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] Docs: An initial automarkup extension for sphinx Message-ID: <20190624133852.4a31c597@coco.lan> In-Reply-To: <20190624082950.5e338d37@lwn.net> References: <20190621235159.6992-1-corbet@lwn.net> <20190621235159.6992-2-corbet@lwn.net> <20190621220046.3de30d9d@coco.lan> <20190622084346.28c7c748@lwn.net> <20190622144610.26b7d99c@coco.lan> <20190624082950.5e338d37@lwn.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, 24 Jun 2019 08:29:50 -0600 Jonathan Corbet escreveu: > On Sat, 22 Jun 2019 14:46:10 -0300 > Mauro Carvalho Chehab wrote: > > > > > .. c:function:: int ioctl( int fd, int request, void *argp ) > > > > :name: v4l2-ioctl > > > > > > Some digging around didn't turn up any documentation for :name:, but it > > > seems to prevent ioctl() from going into the list of functions that can be > > > cross-referenced. > > > > It took me a while to discover this way to be able to re-define the > > name of a symbol at the C domain, but I'm pretty sure I read this > > somewhere at the Sphinx docs (or perhaps on some bug track or Stack > > Overflow). > > > > I don't remember exactly where I get it, but I guess it is related to > > this: > > > > http://docutils.sourceforge.net/docs/howto/rst-roles.html > > > > > I wonder if the same should be done for the others? > > > > Sure. > > It actually occurs to me that it might be better to keep the skip list and > maybe expand it. There are vast numbers of places where people write > open() or whatever(), and there is no point in even trying to > cross-reference them. Yeah, subsystems will likely have their own "man pages" for for sysctls. Both the dvb and the v4l2 ones are part of what used to be the DocBook manpages for those syscalls. If I'm not mistaken, we ended by expanded the same approach for the media controller, for CEC and for RC. > I should do some tests, it might even make a > measurable difference in the build time to skip them :) And in any case, > somebody is bound to put one of those common names into the namespace in > the future, recreating the current problem. There is one way of keeping it while avoiding troubles: you could create internal names, for example using the current dir, auto-adding the ":name:" tag when a declaration conflict rises. Not sure how easy/hard would be to implement it. Btw, at get_abi.pl, I had to do a trick like that, as some symbols have a "local context". The good thing at ABI files is that the context is clear: it is valid only between "What:" and "Description:" fields. Also, as it is a single script that parses the entire ABI (it takes on ~0.1 seconds to parse everything and store internally on my machine), the logic there detects when an existing symbol is re-used on a different context. When this happens, it adds a random char at the end of the internal reference, while keeping the original name[1]. [1] on the the highly unlikely event that the new name still repeats, it adds a new random char - until the name gets different. Probably doing it at automarkup won't be that simple, but it could work. Thanks, Mauro