Re: Inline emphasis warnings
> Am 09.09.2017 um 18:46 schrieb Randy Dunlap :
>
> Hi,
>
> What is the suggested way(s) to fix this warning:
>
> ../kernel/sched/fair.c:7584: WARNING: Inline emphasis start-string without
> end-string.
>
> from this source:
>
> * this CPU. The amount of the imbalance is returned in *imbalance.
>
>
> I have a patch that changes that to env->imbalance, but what I am really
> looking
> for is a way to include a '*' in the kernel-doc, for cases like this:
>
> /**
> * foofunc - do the bar and update its value
> * @bar: pointer to input value, to be updated for return
> *
> * fu the *bar with baz
> */
> void foofunc(unsigned long long *bar, unsigned long long baz)
> {
> *bar = *bar + 42 * baz;
> *bar %= baz;
> }
>
Hy Randy,
since kernel-doc comments are reST markup, I recommend to use ``*bar``
which is rendered as "inline literal" (monspace).
see ``inline literal``:
http://docutils.sourceforge.net/docs/user/rst/quickref.html#inline-markup
One to alternative to "inline literal" is to escape reST markup with a
backslash, e.g.: \*bar
For backslash escape see:
http://docutils.sourceforge.net/docs/user/rst/quickref.html#escaping
-- Markus --
>
> thanks.
> --
> ~Randy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
Hi Sam, 2017-09-09 15:39 GMT+09:00 Sam Ravnborg : > On Fri, Sep 08, 2017 at 02:38:23PM -0700, Linus Torvalds wrote: >> On Fri, Sep 8, 2017 at 11:39 AM, Linus Torvalds >> wrote: >> > >> > Strange. Does anybody see what the pattern to the failure is? >> >> Found it. Stupid special case for 'typeof()' that used >> is_reserved_word() in ways I hadn't realized. >> >> Fix committed. > > To get bonus points for this cleanup you should also remove > the now unused gpref support in Makefile.lib > > Sam Yes. Linus committed c054be10ffd Thanks! -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
Hi Linus, 2017-09-09 6:38 GMT+09:00 Linus Torvalds : > On Fri, Sep 8, 2017 at 11:39 AM, Linus Torvalds > wrote: >> >> Strange. Does anybody see what the pattern to the failure is? > > Found it. Stupid special case for 'typeof()' that used > is_reserved_word() in ways I hadn't realized. > > Fix committed. > > Linus "is_reserved_word()" sounds like a boolean function that returns 1 or 0. Maybe, the choice of the function name was not nice. Anyway, thanks a lot for taking care of all this! -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Sun, Sep 10, 2017 at 6:58 AM, Masahiro Yamada wrote: > > "is_reserved_word()" sounds like a boolean function > that returns 1 or 0. > Maybe, the choice of the function name was not nice. Yeah, not great name. That's the old name, though - I didn't change that part, I just changed how it used to return the token structure pointer, which would be NULL when it wasn't a keyword. I actually *should* have made it just return 0 for the "not a keyword" case rather than -1, and that would have ended up being semantically closer to the old use (because you could treat the return value as a boolean, like you could with the token pointer). But it's been literally decades since I used bison/flex, and I didn't remember the rules for 'enum yytokentype', so I just thought "negative numbers for error" was safer. Zero would have been fine, no token can have that number anyway (it just means EOF). And negative wasn't safer, it caused that bug due to the bare boolean use I hadn't noticed. Oh well. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
