I'm excited to see this being discussed again - it's been years since
the last attempt. I've tried to stay out of the conversation, but I
feel obligated say something and then go back to lurking.
On Tue, Sep 26, 2017 at 10:26 AM, Johannes Weiner wrote:
> On Tue, Sep 26, 2017 at 03:30:40PM +0200,
Hi Mauro,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.14-rc2 next-20170926]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/scripts-kernel-doc
On 09/26/17 10:59, Mauro Carvalho Chehab wrote:
> kernel-doc-nano-HOWTO.txt has a chapter about man pages
> production. While we don't have a working "make manpages"
> target, add it.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/doc-guide/kernel-doc.rst | 61
> +++
On 09/26/17 10:59, Mauro Carvalho Chehab wrote:
> Add a new section to describe kernel-doc arguments,
> adding examples about how identation should happen, as failing
> to do that causes Sphinx to do the wrong thing.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/doc-guide/kernel
tree: git://git.lwn.net/linux-2.6 docs-next
head: 5cb5c31cdf246099f7d48a57f448b05b7941cd6a
commit: 5cb5c31cdf246099f7d48a57f448b05b7941cd6a [9/9] scripts/kernel-doc: warn
on excess enum value descriptions
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1)
On Tue, 26 Sep 2017, Michal Hocko wrote:
> > No, I agree that we shouldn't compare sibling memory cgroups based on
> > different criteria depending on whether group_oom is set or not.
> >
> > I think it would be better to compare siblings based on the same criteria
> > independent of group_oom
Em Tue, 26 Sep 2017 14:59:19 -0300
Mauro Carvalho Chehab escreveu:
> There are several places within the Kernel tree with nested
> structs/unions, like this one:
>
> struct ingenic_cgu_clk_info {
> const char *name;
> enum {
> CGU_CLK_NONE = 0,
> CGU_CLK_EXT = BIT(0),
>
Em Tue, 26 Sep 2017 18:56:10 +0200
Markus Heiser escreveu:
> > Am 25.09.2017 um 20:22 schrieb Mauro Carvalho Chehab
> > :
> >
> > Jon,
> >
> > Please let me know what you think about this approach. IMHO, it is a way
> > better than what we do right now. This is more a proof of concept, as the
Em Tue, 26 Sep 2017 14:45:08 +0200
Markus Heiser escreveu:
> > Am 25.09.2017 um 20:41 schrieb Mauro Carvalho Chehab
> > :
>
> >>> + $cont = 1;
> >>> + };
> >>> + };
> >>> + # Ignore other nested elements, like enums
> >>> + $members =~ s/({[^\{\}]*})//g;
> >>> + $neste
Ping?
On Wed, Sep 13, 2017 at 09:08:30PM +0300, Yury Norov wrote:
> The Documentation/arm64/memory.txt says:
> When using KVM, the hypervisor maps kernel pages in EL2, at a fixed
> offset from the kernel VA (top 24bits of the kernel VA set to zero):
>
> In fact, kernel addresses are transleted to
Describe nested struct/union fields
NOTE: This is a pure test patch, meant to validate if the
parsing logic for nested structs is working properly.
I've no idea if the random text I added there is correct!
Signed-off-by: Mauro Carvalho Chehab
---
drivers/w1/w1_netlink.h | 4
1 file change
Since there isn't any docbook code anymore upstream,
we can get rid of several output formats:
- docbook/xml, html, html5 and list formats were used by
the old build system;
- As ReST is text, there's not much sense on outputting
on a different text format.
After this patch, only man and rst
There is a mess on this chapter: it suggests that even
enums and unions should be documented with "struct". That's
not the way it should be ;-)
Fix it and move it to happen earlier.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kern
There are several places within the Kernel tree with nested
structs/unions, like this one:
struct ingenic_cgu_clk_info {
const char *name;
enum {
CGU_CLK_NONE = 0,
CGU_CLK_EXT = BIT(0),
CGU_CLK_PLL = BIT(1),
CGU_CLK_GATE = BIT(2),
CGU_CLK_MUX = BIT(3),
Right now, it is not possible to document nested struct and nested unions.
kernel-doc simply ignore them.
Add support to document them.
This series starts with a patch getting rid of the now unused output formats
for kernel-doc: since we got rid of all DocBook stuff, we should not need
them anymo
Add documentation about typedefs for function prototypes and
move it to happen earlier.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kernel-doc.rst | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/Documentation/doc-guide/k
Move its contents to happen earlier and improve the description
of return values, adding a subsection to it. Most of the contents
there came from kernel-doc-nano-HOWTO.txt.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kernel-doc.rst | 100 -
1
Everything there is already described at
Documentation/doc-guide/kernel-doc.rst. So, there's no reason why
to keep it anymore.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/00-INDEX | 2 -
Documentation/kernel-doc-nano-HOWTO.txt | 322
The private members section can now be moved to be together
with the arguments section. Move it there and add an example
about the usage of public:
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kernel-doc.rst | 56 ++
1 file changed, 30 insertio
kernel-doc-nano-HOWTO.txt has a chapter about man pages
production. While we don't have a working "make manpages"
target, add it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kernel-doc.rst | 61 ++
1 file changed, 47 insertions(+), 14 deletio
Add a new section to describe kernel-doc arguments,
adding examples about how identation should happen, as failing
to do that causes Sphinx to do the wrong thing.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/kernel-doc.rst | 44 +++---
1 file chang
This two-patch series attempts to speed incremental builds of the
kernel up by a bit. How much of a speedup you get depends a lot on
your environment, specifically the speed of your workstation and how
fast it takes to invoke the compiler.
In the Chrome OS build environment you get a really big w
While timing a "no-op" build of the kernel (incrementally building the
kernel even though nothing changed) in the Chrome OS build system I
found that it was much slower than I expected.
Digging into things a bit, I found that quite a bit of the time was
spent invoking the C compiler even though we
On Tue, Sep 26, 2017 at 03:30:40PM +0200, Michal Hocko wrote:
> On Tue 26-09-17 13:13:00, Roman Gushchin wrote:
> > On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote:
> > > On Tue 26-09-17 11:59:25, Roman Gushchin wrote:
> > > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrot
> Am 25.09.2017 um 20:22 schrieb Mauro Carvalho Chehab
> :
>
> Jon,
>
> Please let me know what you think about this approach. IMHO, it is a way
> better than what we do right now. This is more a proof of concept, as the
> patch is not complete.
>
> With it, we can now document both anonymous
On Tue 26-09-17 13:13:00, Roman Gushchin wrote:
> On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote:
> > On Tue 26-09-17 11:59:25, Roman Gushchin wrote:
> > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote:
> > > > On Mon 25-09-17 19:15:33, Roman Gushchin wrote:
> > > > [..
On 09/26/2017 07:48 AM, Petr Mladek wrote:
> On Mon 2017-09-18 13:51:00, Prarit Bhargava wrote:
>> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
>> timestamp to printk messages. The local hardware clock loses time each
>> day making it difficult to determine exactly w
> Am 25.09.2017 um 20:41 schrieb Mauro Carvalho Chehab
> :
>>> + $cont = 1;
>>> + };
>>> + };
>>> + # Ignore other nested elements, like enums
>>> + $members =~ s/({[^\{\}]*})//g;
>>> + $nested = $decl_type;
>>
>> What is the latter good for? I guess the 'n
On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote:
> On Tue 26-09-17 11:59:25, Roman Gushchin wrote:
> > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote:
> > > On Mon 25-09-17 19:15:33, Roman Gushchin wrote:
> > > [...]
> > > > I'm not against this model, as I've said before
On Mon 2017-09-18 13:51:00, Prarit Bhargava wrote:
> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
> timestamp to printk messages. The local hardware clock loses time each
> day making it difficult to determine exactly when an issue has occurred in
> the kernel log, and
On Tue 26-09-17 11:59:25, Roman Gushchin wrote:
> On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote:
> > On Mon 25-09-17 19:15:33, Roman Gushchin wrote:
> > [...]
> > > I'm not against this model, as I've said before. It feels logical,
> > > and will work fine in most cases.
> > >
> > >
On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko wrote:
> On Mon 25-09-17 19:15:33, Roman Gushchin wrote:
> [...]
> > I'm not against this model, as I've said before. It feels logical,
> > and will work fine in most cases.
> >
> > In this case we can drop any mount/boot options, because it p
On Mon 25-09-17 15:21:03, David Rientjes wrote:
> On Mon, 25 Sep 2017, Johannes Weiner wrote:
>
> > > True but we want to have the semantic reasonably understandable. And it
> > > is quite hard to explain that the oom killer hasn't selected the largest
> > > memcg just because it happened to be in
33 matches
Mail list logo
