[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200108161428.GA263696@mit.edu>
Date: Wed, 8 Jan 2020 11:14:28 -0500
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Markus Elfring <Markus.Elfring@....de>
Cc: Enrico Weigelt <lkml@...ux.net>, linux-doc@...r.kernel.org,
kernel-janitors@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Improving documentation for programming interfaces
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
Powered by blists - more mailing lists