Re: Generic kernel features that need architecture(mips) support

3 messages, 3 authors, 2015-06-11 · open the first message on its own page

Re: Generic kernel features that need architecture(mips) support

From: Xose Vazquez Perez <hidden>
Date: 2015-06-10 16:37:11

On 06/10/2015 04:58 PM, Ralf Baechle wrote:
How are the documentation files in Documentation/features/ maintained?
They were automatically generated so I wonder if I have to take care
of anything.
CC: Ingo and related ml.

Re: Generic kernel features that need architecture(mips) support

From: Ingo Molnar <mingo@kernel.org>
Date: 2015-06-11 06:25:05

(Jon Cc:-ed)

* Xose Vazquez Perez [off-list ref] wrote:
On 06/10/2015 04:58 PM, Ralf Baechle wrote:
quoted
How are the documentation files in Documentation/features/ maintained?
They were automatically generated so I wonder if I have to take care
of anything.
CC: Ingo and related ml.
So changes to Documentation/features/ should come as simple patches done from hand 
editing, there's no need to preserve any initial (half-)automated generation. 
Formatting should be preserved so that Documentation/features/list-arch.sh still 
works as before.

Jon: would you like to receive all patches to Documentation/features/ so you can 
collect them in the documentation tree, or can maintainers patch it as part of any 
feature work that affects the tables? I think it's all finegrained enough to not 
create conflicts. That way they would become partly self-maintaining. (Or at least 
one can always hope! ;-)

Thanks,

	Ingo

Re: Generic kernel features that need architecture(mips) support

From: Jonathan Corbet <corbet@lwn.net>
Date: 2015-06-11 13:18:02

On Thu, 11 Jun 2015 08:24:53 +0200
Ingo Molnar [off-list ref] wrote:
Jon: would you like to receive all patches to Documentation/features/ so you can 
collect them in the documentation tree, or can maintainers patch it as part of any 
feature work that affects the tables? I think it's all finegrained enough to not 
create conflicts. That way they would become partly self-maintaining. (Or at least 
one can always hope! ;-)
I sort of figured I'd handle it the way I do the rest of Documentation/ —
I'm happy to herd the patches, but I also have no problem staying out of
the way when other maintainers reach into it.

jon
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help