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
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 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: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 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 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"
> 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
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
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,
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
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
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 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, 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 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
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 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
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, 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
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
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
25 matches
Mail list logo
