lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcG544HZ1j_6jvZoba6kEjKXXfZ8deJWmwNQ08mC35NrA@mail.gmail.com>
Date:   Tue, 16 Feb 2021 19:12:58 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jonathan Corbet <corbet@....net>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Documentation List <linux-doc@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: anonymous enums in kernel doc

On Tue, Feb 16, 2021 at 7:05 PM Jonathan Corbet <corbet@....net> wrote:
>
> Andy Shevchenko <andy.shevchenko@...il.com> writes:
>
> > On Tue, Feb 16, 2021 at 6:51 PM Jonathan Corbet <corbet@....net> wrote:
> >>
> >> > Mauro, can you do some test cases in your workflow against anonymous
> >> > enum in ernel doc, please?
> >> >
> >> > They are broken again, please fix the script!
> >> >
> >> > drivers/pinctrl/intel/pinctrl-intel.c:204: warning: wrong kernel-doc
> >> > identifier on line:
> >> > * enum - Locking variants of the pad configuration
> >> >
> >> > Above is simply a wrong statement.
> >>
> >> The real problem, perhaps, is that there seems to be little point in
> >> adding kerneldoc comments for anonymous enums; where are you going to
> >> use that documentation?
> >
> > I had been explicitly told during review (IIRC by maintainers) to make
> > it such, while the initial version was exactly like you are thinking
> > of. So, I'm not the right person to be asked :-)

Just for a reference [1].

> >>  The error message could perhaps be changed to
> >> say that; meanwhile, perhaps this one could be fixed with an action like
> >> s%/**%/*% ?
> >
> > See above. I think regression comes from the kernel doc script,
> > earlier it was okay. That said, the author of kernel doc changes has
> > to submit a patch to amend the driver and maintainers will review it.
>
> kerneldoc now warns about various incorrect things that it used to just
> silently pass over.  There is no regression here, just a new diagnostic
> to point out something that was never going to work right.  Unless you
> have a good idea for what kerneldoc should do with a block like that?

As it does, put description of individual fields and prepend it with a
common part.

So,

enum - Bla bla bla
 @FOO: ABC
 @BAR: DEF
Description

Should go in the doc for the corresponding file like (as an example)

Anonymous enumeration Bla bla bla
Description

FOO ABC
BAR DEF

(not sure about indentation, emphasizing and separators, but I think
you got the idea).

> (An alternative fix, of course, would be to give the enum a name so it
> can actually be used for type checking.)

That enum is not used as an enum, it provides the logically unified constants.

Personally I don't see why the kernel doc can't digest this.

[1]: https://patchwork.ozlabs.org/project/linux-gpio/patch/20190808132128.13359-1-andriy.shevchenko@linux.intel.com/

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ