Message ID | 20240109135952.77458-1-warthog618@gmail.com |
---|---|
Headers | show |
Series | Documentation: gpio: add character device userspace API documentation | expand |
On Wed, Jan 10, 2024 at 01:10:51PM +0200, Andy Shevchenko wrote: > On Wed, Jan 10, 2024 at 10:16 AM Vegard Nossum <vegard.nossum@oracle.com> wrote: > > On 10/01/2024 00:45, Kent Gibson wrote: > > > On Tue, Jan 09, 2024 at 10:00:26PM +0200, Andy Shevchenko wrote: > > >> On Tue, Jan 9, 2024 at 4:00 PM Kent Gibson <warthog618@gmail.com> wrote: > > >> > > >> May we actually state in the documentation that sysfs is subject to > > >> remove at some point? > > > > > > So formally define what "deprecated" means? > > > Is that covered in the higher level documentation somewhere? > > > If so I'm more than happy to provide a reference. > > > > We have a few files that may be relevant here, that I'm aware of: > > > > 1) https://docs.kernel.org/admin-guide/sysfs-rules.html > > > > documents some general assumptions that userspace can make about the > > stability of sysfs and its files > > > > 2) https://docs.kernel.org/admin-guide/abi.html > > > > This is the public-facing, somewhat machine-readable repository of what > > is supposed to be the kernel's ABI/API, including "obsolete" and > > "removed" interfaces. > > > > 3) Documentation/ABI/README > > > > describes the process of deprecating an interface > > Yes and GPIO currently is under obsolete section with also this: > > "This ABI is deprecated and will be removed after 2020. It is replaced > with the GPIO character device." > > https://docs.kernel.org/admin-guide/abi-obsolete.html#symbols-under-sys-class > > So, proposed cleanup series should probably rely on this documentation > among other existing descriptions of sysfs GPIO. > The sysfs doc already references the doc (sysfs-gpio) that generates the HTML that link points to, so not sure what to change. I can't include a direct reference to the HTML, AFAICT, as that HTML is generated using kernel-abi makefile magic so the usual doc path cross-references don't work - you just get the path as plain text. If there is some way to provide a cross-reference that generates to that link then I'll change it, but I don't know how. >>> + - - ``EFAULT`` > Wondering if these constants can be referenced via % and if it makes sense. That would be great and I do want to do that, particularly for the uAPI v1 docs that use a lot of consts rather than enums, but, AFAICT, you can't create cross-references for consts, you can only add formatting[1]. And the % formatting only works in kernel-doc, in rst you have to add it explicitly yourself, hence the ``EFAULT`` . Cheers, Kent. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#highlights-and-cross-references
On Tue, Jan 09, 2024 at 09:59:45PM +0800, Kent Gibson wrote: > My new year's resolution was to improve the documentation of the > character device API and gpio in general, so here we are. > > > Patch 2 relocates the sysfs API doc to stress its deprecation by > moving it to a new deprecated section, again in userspace-api but > with a similar section in the admin-guide. The deprecated section > also provides a placeholder for subsequent changes. > While preparing the v2 version of this series, I'm now wondering if this should be changed to "obsolete" rather than "deprecated", to better fit with the interface lifecycle, to indicate there is an alternative, and to emphasise that it is scheduled for removal. i.e. from a userspace perspective "obsolete" is the clearer term. Is that a change worth making? Cheers, Kent.
On Sun, Jan 14, 2024 at 4:47 AM Kent Gibson <warthog618@gmail.com> wrote: > On Tue, Jan 09, 2024 at 09:59:45PM +0800, Kent Gibson wrote: > > My new year's resolution was to improve the documentation of the > > character device API and gpio in general, so here we are. ... > While preparing the v2 version of this series, I'm now wondering > if this should be changed to "obsolete" rather than "deprecated", to > better fit with the interface lifecycle, to indicate there is an > alternative, and to emphasise that it is scheduled for removal. > i.e. from a userspace perspective "obsolete" is the clearer term. > > Is that a change worth making?
On Sun, Jan 14, 2024 at 02:01:29PM +0200, Andy Shevchenko wrote: > On Sun, Jan 14, 2024 at 4:47 AM Kent Gibson <warthog618@gmail.com> wrote: > > On Tue, Jan 09, 2024 at 09:59:45PM +0800, Kent Gibson wrote: > > > My new year's resolution was to improve the documentation of the > > > character device API and gpio in general, so here we are. > > ... > > > While preparing the v2 version of this series, I'm now wondering > > if this should be changed to "obsolete" rather than "deprecated", to > > better fit with the interface lifecycle, to indicate there is an > > alternative, and to emphasise that it is scheduled for removal. > > i.e. from a userspace perspective "obsolete" is the clearer term. > > > > Is that a change worth making? > > From my p.o.v. yes, as it makes it consistent with what we already > have in the sysfs/obsolete. > Ok then, I'll incorporate it into v2. Cheers, Kent.