We don't just need better doc toolchains, we also need better docs for
our doc toolchain!
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
---
Documentation/kernel-documentation.rst | 7 ++-
1 file changed, 6 insertions(+), 1
On Thu, 17 Nov 2016, Daniel Vetter wrote:
> We don't just need better doc toolchains, we also need better docs for
> our doc toolchain!
Mea culpa. Thanks, LGTM.
BR,
Jani.
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Jonathan Corbet
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: Daniel Vett
On Thu, 17 Nov 2016, Jani Nikula wrote:
> On Thu, 17 Nov 2016, Daniel Vetter wrote:
>> We don't just need better doc toolchains, we also need better docs for
>> our doc toolchain!
>
> Mea culpa. Thanks, LGTM.
Oh, the example struct now has too "foo" fields, documented
twice. That's not good.
BR
We don't just need better doc toolchains, we also need better docs for
our doc toolchain!
v2: Make sure we don't have foo twice (Jani).
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
---
Documentation/kernel-documentation.rst
On Thu, 17 Nov 2016, Daniel Vetter wrote:
> We don't just need better doc toolchains, we also need better docs for
> our doc toolchain!
>
> v2: Make sure we don't have foo twice (Jani).
Thanks, *now* LGTM. :)
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Jonathan Corbet
> Cc: linux-doc@vger.k
Provide a man page for parse-headers.pl, describing
how to use it.
The documentation on ReST format was generated via pod2rst:
http://search.cpan.org/~dowens/Pod-POM-View-Restructured-0.02/bin/pod2rst
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/index.rst |
Having the kernel-documentation at the topmost level doesn't
allow generating a separate PDF file for it. Also, makes harder
to add extra contents. So, place it on a sub-dir.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/00-INDEX | 2 +-
Documentation/conf.
The Kernel documentation guide is currently a single file at the top of
Documentation/ dir. Sphinx works best if the documentation is
inside a subdirectory, as otherwise there's no way to have a PDF book
with its contents, without including everything else.
The first patch on this series address t
The pod2rst tool generated a man page for parse-headers.pl
script, but it is better to put it into some context.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/parse-headers.rst | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/Docu
On Wednesday, November 16, 2016 6:26:33 PM CET Mauro Carvalho Chehab wrote:
> Em Wed, 16 Nov 2016 17:03:47 +0100
> Arnd Bergmann escreveu:
>
> > On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> > > It basically calls ImageMagick "convert" tool for all png and
> > > pdf f
On Thu, 17 Nov 2016, Arnd Bergmann wrote:
> On Wednesday, November 16, 2016 6:26:33 PM CET Mauro Carvalho Chehab wrote:
>> Em Wed, 16 Nov 2016 17:03:47 +0100
>> Arnd Bergmann escreveu:
>>
>> > On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
>> > > It basically calls Imag
On Wed, Nov 09, 2016 at 06:36:20PM -0600, Tom Lendacky wrote:
> The boot data and command line data are present in memory in an
> un-encrypted state and are copied early in the boot process. The early
> page fault support will map these areas as encrypted, so before attempting
> to copy them, add
On Thu, Nov 17, 2016 at 8:02 AM, Linus Torvalds
wrote:
>
> No. That is how I *noticed* the issue. Those stupid pdf binary files
> have been around forever, I just didn't notice until the Fedora people
> started complaining about the patches.
Side note: my release patches these days enable both "-
On Thu, 2016-11-17 at 13:16 -0200, Mauro Carvalho Chehab wrote:
> Hi Ted,
>
> Em Thu, 17 Nov 2016 09:52:44 -0500
> Theodore Ts'o escreveu:
>
> > On Thu, Nov 17, 2016 at 12:07:15PM +0100, Arnd Bergmann wrote:
> > > [adding Linus for clarification]
> > >
> > > I understood the concern as being ab
Em Thu, 17 Nov 2016 12:07:15 +0100
Arnd Bergmann escreveu:
> On Wednesday, November 16, 2016 6:26:33 PM CET Mauro Carvalho Chehab wrote:
> > Em Wed, 16 Nov 2016 17:03:47 +0100
> > Arnd Bergmann escreveu:
> >
> > > On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> >
On Wed, Nov 16, 2016 at 03:22:26PM +0400, Maxim Kuvyrkov wrote:
> Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32
> to have extra failures compared to LP64, since these are not
> regressions, but, rather, failures of a new configuration.
I disagree with this. We definitely n
Em Thu, 17 Nov 2016 13:28:29 +0200
Jani Nikula escreveu:
> On Thu, 17 Nov 2016, Arnd Bergmann wrote:
> > On Wednesday, November 16, 2016 6:26:33 PM CET Mauro Carvalho Chehab wrote:
> >
> >> Em Wed, 16 Nov 2016 17:03:47 +0100
> >> Arnd Bergmann escreveu:
> >>
> >> > On Tuesday, November 8,
Hi Ted,
Em Thu, 17 Nov 2016 09:52:44 -0500
Theodore Ts'o escreveu:
> On Thu, Nov 17, 2016 at 12:07:15PM +0100, Arnd Bergmann wrote:
> > [adding Linus for clarification]
> >
> > I understood the concern as being about binary files that you cannot
> > modify with classic 'patch', which is a separ
> So, the problem that remains is for those images whose source
> is a bitmap. If we want to stick with the Sphinx supported formats,
> we have only two options for bitmaps: jpg or png. We could eventually
> use uuencode or base64 to make sure that the patches won't use
> git binary diff extension
On Thu, Nov 17, 2016 at 12:07:15PM +0100, Arnd Bergmann wrote:
> [adding Linus for clarification]
>
> I understood the concern as being about binary files that you cannot
> modify with classic 'patch', which is a separate issue.
I think the other complaint is that the image files aren't "source"
On Wed, Nov 09, 2016 at 06:36:55PM -0600, Tom Lendacky wrote:
> This patch adds support to be change the memory encryption attribute for
> one or more memory pages.
"Add support for changing ..."
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cacheflush.h |3 +
> arch/x86/inclu
On Wed, Nov 09, 2016 at 06:36:31PM -0600, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be accessed unencrypted. Add support to apply the
> proper attributes to the EFI page tables and to the early_memremap and
> memremap APIs
On Thu, Nov 17, 2016 at 3:07 AM, Arnd Bergmann wrote:
>
> [adding Linus for clarification]
>
> I understood the concern as being about binary files that you cannot
> modify with classic 'patch', which is a separate issue.
No. That is how I *noticed* the issue. Those stupid pdf binary files
have b
On Wed, Nov 09, 2016 at 06:37:08PM -0600, Tom Lendacky wrote:
> When Secure Memory Encryption is enabled, the trampoline area must not
> be encrypted. A CPU running in real mode will not be able to decrypt
> memory that has been encrypted because it will not be able to use addresses
> with the memo
On Wed, 2016-11-16 at 15:22 +0400, Maxim Kuvyrkov wrote:
> >
> > On Nov 9, 2016, at 1:56 PM, Yury Norov
> > wrote:
> >
> > >
> > > Below is the results of glibc testsuite run for aarch64/lp64
I have been running the glibc testsuite as well. I have only run it on
an ILP32 enabled kernel. Usin
25 matches
Mail list logo
