Daniel Vetter writes:
> On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick wrote:
>> Since we just had a big discussion about this on mesa-dev w.r.t. Mesa
>> code and documentation... does the kernel have a policy about which
>> flavor (pun intended) of English should be used?
>
> I'm not finding it
On Tue, 19 Jul 2016 13:42:54 +0200
Daniel Vetter wrote:
> Unfortunately warnings generated after parsing in sphinx can end up
> with entirely bogus files and line numbers as sources. Strangely for
> outright errors this is not a problem. Trying to convert warnings to
> errors also doesn't fix it.
On Thu, 13 Jun 2019 07:10:36 -0300
Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists
On Tue, 18 Jun 2019 10:33:58 -0300
Mauro Carvalho Chehab wrote:
> here are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> This patch is against today's next-20190617 branch. Not su
On Sun, 13 Oct 2019 13:53:59 +0800
Changbin Du wrote:
> The 'functions' directive is not only for functions, but also works for
> structs/unions. So the name is misleading. This patch renames it to
> 'specific', so now we have export/internal/specific directives to limit
> the functions/types to
On Sun, 20 Oct 2019 21:17:17 +0800
Changbin Du wrote:
> The 'functions' directive is not only for functions, but also works for
> structs/unions. So the name is misleading. This patch renames it to
> 'identifiers', which specific the functions/types to be included in
> documentation. We keep the
On Tue, 29 Oct 2019 08:31:22 +0800
Changbin Du wrote:
> Here python is different from C. Both empty string and None are False in
> python.
> Note such condition is common in python.
Treating both as a False value is reasonably common. Treating them
elsewhere in the same code block as separate
On Fri, 19 Aug 2016 11:52:15 +1000
Stephen Rothwell wrote:
> Today's linux-next merge of the jc_docs tree got a conflict in:
>
> Documentation/gpu/index.rst
>
> between commit:
>
> b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc")
>
> from the drm-misc tree and commit:
>
> 505
On Wed, 25 Nov 2015 18:07:59 +0100
Daniel Vetter wrote:
> Unfortunately the entire improved docbook project died at KS in a
> massive bikeshed. So we need to carry this around in drm private trees
> forever :(
I don't think that's an entirely helpful way to look at things, honestly.
Changing how
On Fri, 9 Dec 2016 19:53:04 +0100
Daniel Vetter wrote:
> Not yet everything in this area, I still want to sprinkle nice docs around all
> the fence code. Especially some text to explain implicit vs. explicit fencing
> and how it's all supposed to work.
>
> But just cleanup in the dma-buf part w
On Sun, 11 Dec 2016 13:35:49 +0100
Daniel Vetter wrote:
> > It seems like just the sort of thing we want to be doing to pull the docs
> > together in a more rational way.
>
> Ok if we pull this in through gfx trees? Will miss 4.10 though, that's
> already finished and in bugfix-only mode.
I'v
On Sun, 11 Dec 2016 18:35:42 +0100
Daniel Vetter wrote:
> > Here's a thought, though: how about if we slip in a little version of
> > dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the
> > rest of the set could go through your tree without touching
> > driver-api/index.rst a
On Fri, 9 Dec 2016 19:53:05 +0100
Daniel Vetter wrote:
> Just prep work to polish and consolidate all the dma-buf related
> documenation.
>
> Unfortunately I didn't discover a way to both integrate this new file
> into the overall toc while keeping it at the current place. Work
> around that by
On Tue, 17 Nov 2015 08:40:46 -0200
Mauro Carvalho Chehab wrote:
> The above causes some versions of perl to fail, as keys expect a
> hash argument:
>
> Execution of .//scripts/kernel-doc aborted due to compilation errors.
> Type of arg 1 to keys must be hash (not private array) at
> .//scripts/
On Tue, 17 Nov 2015 13:29:49 -0200
Mauro Carvalho Chehab wrote:
> The enclosed patch should do the trick. I tested it with perl 5.10 and
> perl 5.22 it worked fine with both versions.
Indeed it seems to work - thanks! Applied to the docs tree, I'll get it
upstream before too long.
jon
___
On Sat, 12 Dec 2015 12:13:45 +0100
Daniel Vetter wrote:
> I just figured there's no way this could get it, and I'd
> much rather improve the docs themselves than trying to convince core
> kernel folks that this might be useful.
So I'm not quite sure why you figured that; I never said it, certain
On Thu, 14 Jan 2016 22:03:26 +0200
Jani Nikula wrote:
> What if we added support for some markup language as an alternative to
> DocBook for the high level documentation? What if we taught kernel-doc
> to output said markup natively, and included those generated pieces into
> the high level docum
On Fri, 16 Feb 2018 11:48:14 -0200
Mauro Carvalho Chehab wrote:
> his series fix two bugs at kernel-doc.rst examples and add support
> for in-line nested struct comments.
>
> It also converts one documentation at intel_dpio_phy to use it,
> in order to give a practical example about how to use i
On Tue, 1 Sep 2015 14:57:33 -0300
Danilo Cesar Lemes de Paula wrote:
> Did you find time to check this patch? As you mentioned that you applied
> the Markdown support for the linux-next tree, this patch might be needed
> (maybe "wanted" is a better word).
Not quite what I said...I said I'd apply
On Fri, 4 Sep 2015 14:53:34 -0300
Danilo Cesar Lemes de Paula wrote:
> In the last few days I sent three features:
> Markdown support (patch series 1)
> Cross-reference hyperlink support (patch series 1)
> in-struct-body documentation (series 2)
>
> I assume you want a new patch series for the s
On Tue, 1 Sep 2015 14:44:14 -0300
Danilo Cesar Lemes de Paula wrote:
> Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to
> avoid duplicated documentation in the next call.
> It works for most of the cases, but there are some specific situations
> where a struct has the same name of
On Mon, 7 Sep 2015 17:01:58 -0300
Danilo Cesar Lemes de Paula wrote:
> The following series contains:
> * kernel-doc: markdown support and improvements.
OK, I've spent a while looking this stuff over. I like the general idea,
but I do have a couple of concerns.
1 Installing pandoc on a Fedor
On Sun, 13 Sep 2015 12:36:07 +0200
Daniel Vetter wrote:
> Personally I don't care which kind of text markup we pick and wich
> converter, as long as the project looks reasonable far away from
> immeninent death (way too many one-person projects on github in this
> area).
>
> But if we have this
On Mon, 7 Sep 2015 17:01:59 -0300
Danilo Cesar Lemes de Paula wrote:
> The "highlight" code is very sensible to the order of the hash keys,
> but the order of the keys cannot be predicted. It generates
> faulty DocBook entries like:
> - @device_for_each_child
>
> Sorting the result is not
On Mon, 28 Sep 2015 10:36:59 +0100
Graham Whaley wrote:
> I've still not thought of a way of tweaking the kernel-doc and pandoc
> processing to work around this either, as they are done as different
> passes/phases that neither has knowledge about the others
> requirements.
>
> As it stands, I'm
On Fri, 26 Jun 2015 12:08:57 -0300
Danilo Cesar Lemes de Paula wrote:
> To ease the navigation in the documentation we should use inside
> those tags so readers can easily jump between methods directly.
>
> This was discussed in 2014[1] and is implemented by getting a list
> of from the DocBoo
On Thu, 23 Jul 2015 15:16:23 -0300
Danilo Cesar Lemes de Paula wrote:
> This series add supports for hyperlink cross-references on Docbooks and
> an optional markup syntax for in-source Documentation.
I like the idea; just be warned that it's likely to be a week or two and
one more ocean crossin
On Fri, 31 Jul 2015 18:06:45 -0300
Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
>
> Keeping the arguments list inside the struct b
On Mon, 3 Aug 2015 10:23:19 +0200
Daniel Vetter wrote:
> > I'm wondering if we need a kernel summit session on commenting
> > conventions, markdown-in-kerneldoc, etc? Maybe I'll stick a proposal out
> > there.
>
> Might be useful, but I'm not sure how many people really would actively
> work
On Tue, 4 Aug 2015 09:04:08 -0300
Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
>
> Keeping the arguments list inside the struct b
On Thu, 13 Aug 2015 20:09:35 -0300
Danilo Cesar Lemes de Paula wrote:
> Did you find time to take a look on this?
No. Just when I thought things couldn't get crazier, my laptop died.
https://plus.google.com/+JonathanCorbet/posts/FBHp48dPb95
What spare time I had has been dedicated t
On Tue, 28 Jul 2015 16:45:15 -0300
Danilo Cesar Lemes de Paula wrote:
> Functions, Structs and Parameters definitions on kernel documentation
> are pure cosmetic, it only highlights the element.
>
> To ease the navigation in the documentation we should use inside
> those tags so readers can eas
32 matches
Mail list logo
