Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1086815ybl; Wed, 8 Jan 2020 10:46:22 -0800 (PST) X-Google-Smtp-Source: APXvYqyYzLWU0x8fg9C2OTH9P6iQBWAcgTxs8fOaKWvm+LDmRHfDneE6EvLBr9k1+1VjUHePfzTo X-Received: by 2002:a9d:5c86:: with SMTP id a6mr5458342oti.68.1578509182673; Wed, 08 Jan 2020 10:46:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578509182; cv=none; d=google.com; s=arc-20160816; b=z64wnEA+MRcgDs5rsjhmPzr6u0BoGXR7KdbKcbP+YXyZ1SP4XO+yQH7tvMweGsbC6R pGpON2sy58mdgQbNPkLOKDY6BgkY/vqjQucJ+mtwhlXAiHrZOEXnRDPtDhZ2y0DBf1jn jEyo4GRC6EbpXBaxNq+LrU01P5PGRAAKtBbm7wq2VrcBw9jZlxg3r18CnAyA4eA5XXCU FdySjYu8rPAF5gpENk1M1q+majofW6/r6Qj3ZGbH5BBxK8560Jf1PiFED/7LvLlhK9mG zuXNP5E9X6wY4vD8FSn1pb23BmNbVZnFax9IlOd/xbJcoCPlx6c1E4Dvc0OHrnDLZcCW 8XbA== 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; bh=wbojZBFxFHck9wl6bwVEfW0VTY81CFrBrH0o27IRTnU=; b=eNkPta313AEzlnUkAFQ1jQ7SL036zkXVVBbAAT/ADSZBuXWmHS8MrqYkwNBY+br+Zs NC0WawkJHRcFvmxRF5MuPXhc3oOy0g6a6m165F+BztIcmS4RMuGWRgmW+vwq/kXGU+Rq G6XtBCKdqfzRKwba65awiA832NV4XmnINIb6mhnt3m3D2uA1r2r7cis0jHqas7ZA7kXN B14M53NmVc0TosJ09eiWMz7x528GlZBdL2nxYCNO52XCa9edplhenpTofPxkGpt5PLiv i034LdazqQI4MGdriJWCKxr8I7ISNBONziReUZtL4u7TzUDy+3uXWd4b8wDLKmuODwd7 acIA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q12si3055085otr.183.2020.01.08.10.46.10; Wed, 08 Jan 2020 10:46:22 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729230AbgAHQOm (ORCPT + 99 others); Wed, 8 Jan 2020 11:14:42 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:53204 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727428AbgAHQOl (ORCPT ); Wed, 8 Jan 2020 11:14:41 -0500 Received: from callcc.thunk.org (guestnat-104-133-0-111.corp.google.com [104.133.0.111] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 008GEYjR019743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jan 2020 11:14:35 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 0F2E94207DF; Wed, 8 Jan 2020 11:14:29 -0500 (EST) Date: Wed, 8 Jan 2020 11:14:28 -0500 From: "Theodore Y. Ts'o" To: Markus Elfring Cc: Enrico Weigelt , linux-doc@vger.kernel.org, kernel-janitors@vger.kernel.org, LKML Subject: Re: Improving documentation for programming interfaces Message-ID: <20200108161428.GA263696@mit.edu> References: <350cd156-9080-24fe-c49e-96e758d3ca45@web.de> <20191220151945.GD59959@mit.edu> <17931ddd-76ec-d342-912c-faed6084e863@metux.net> <748b8572-a3b3-c084-e8e3-de420f53e468@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <748b8572-a3b3-c084-e8e3-de420f53e468@web.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 08, 2020 at 01:40:45PM +0100, Markus Elfring wrote: > > I propose to encode helpful information into macro calls as needed > for the C programming language. Perhaps it would be useful to for you to express what you are proposing in the form of a patch? That way people can see how disruptive such changes might be, and how hard it might be to maintain them. That's on the "cost" side of the equation. On the "benefits" side of the equation, is there are ways in which it will directly benefit the kernel developers who will need to review the patches and review the annotations, that can be demonstrated immediately? Not in some abstract way, or "when I my research work is completed", but a very concrete way that will be obvious to those of us who are still not completely convinced? If the costs are very small, then the requirement for demonstrating great benefits will also be small. But if the costs are large (e.g., widespread renaming of huge numbers of functions, adding a lot of extra complexity into code paths, use of silly/stupid names such as "TransactionAwarePersistenceManagerFactoryProxy"), then need to show benefits commensurate with such costs will also be great. - Ted