Btw, for your next submission, this patch can be split in two exactly
like the commit message paragraphs are:
On Wed, Nov 09, 2016 at 06:36:10PM -0600, Tom Lendacky wrote:
> Add support to be able to either encrypt or decrypt data in place during
> the early stages of booting the kernel. This does
While the {READ,WRITE}_ONCE() macros should be used in preference to
ACCESS_ONCE(), the circular buffer documentation uses the latter
exclusively.
To point people in the right direction, and as a step towards the
eventual removal of ACCESS_ONCE(), update the documentation to use
READ_ONCE(), as AC
While the {READ,WRITE}_ONCE() macros should be used in preference to
ACCESS_ONCE(), the atomic documentation uses the latter exclusively.
To point people in the right direction, and as a step towards the
eventual removal of ACCESS_ONCE(), update the documentation to use the
{READ,WRITE}_ONCE() mac
> On Nov 9, 2016, at 1:56 PM, Yury Norov wrote:
>
> On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
>> Hi all,
>>
>> [add libc-alpha mail list]
>>
>> For libc-alpha: this is the part of LKML submission with latest
>> patches for aarch64/ilp32.
>> https://www.spinics.net/lists/arm-ke
Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the circular buffer documentation uses the latter
> exclusively.
>
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_ONCE(), update the docum
On Wed, Nov 16, 2016 at 11:12:49AM +, Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the circular buffer documentation uses the latter
> exclusively.
>
> To point people in the right direction, and as a step towards the
> eventual re
On Wed, Nov 16, 2016 at 11:13:59AM +, Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the atomic documentation uses the latter exclusively.
>
> To point people in the right direction, and as a step towards the
> eventual removal of AC
kernel-doc supports documenting struct members "inline" since
a4c6ebede2f9 ("scripts/kernel-doc Allow struct arguments documentation
in struct body"). This requires the inline kernel-doc comments to have
the opening and closing comment markers (/** and */ respectively) on
lines of their own, even f
On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> > [...]
> > > And it may even require "--shell-escape" to be passed at the xelatex
> > > call if inkscape is not in the path, with seems to be a strong
> > > indication that SVG support is not native to texlive, but, instead
On 11/16/2016 4:46 AM, Borislav Petkov wrote:
> Btw, for your next submission, this patch can be split in two exactly
> like the commit message paragraphs are:
I think I originally had it that way, I don't know why I combined them.
I'll split them out.
>
> On Wed, Nov 09, 2016 at 06:36:10PM -060
Hi Arnd,
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 files currently at the documentation (they're all at media,
> > ATM).
>
> It
On Mon, 14 Nov 2016 14:32:32 -0200
Mauro Carvalho Chehab wrote:
One nit...
> diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
> index a7fb35291f6c..297b85c37ab9 100644
> --- a/Documentation/media/Makefile
> +++ b/Documentation/media/Makefile
[...]
> +clean:
> + -rm
There were a few manuals that weren't being built in PDF format, but
there's no reason not to...
Signed-off-by: Jonathan Corbet
---
Documentation/conf.py | 6 ++
Documentation/core-api/conf.py | 5 +
Documentation/security/conf.py | 8
3 files changed, 19 insertions(+)
On Wed, 16 Nov 2016 11:13:59 +
Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the atomic documentation uses the latter exclusively.
>
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_
On Wed, 16 Nov 2016 11:12:49 +
Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the circular buffer documentation uses the latter
> exclusively.
>
> To point people in the right direction, and as a step towards the
> eventual removal
On Mon, 14 Nov 2016 15:52:43 +0100
Oliver Neukum wrote:
> This is a conversion of the USB documentation to the Sphinx format.
> No content was altered or reformatted.
Yay, another template file bites the dust. Applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe li
On Tue, 15 Nov 2016 14:42:14 -0800
Brian Norris wrote:
> Per the original author, the proposed document was never deemed
> necessary, and the important bits got merged into completion.txt. Let's
> just stop confusing readers by pointing at a nonexistent doc.
Makes sense, applied.
Thanks,
jon
-
On Wed, 16 Nov 2016 17:26:16 +0200
Jani Nikula wrote:
> Add support for one line inline comments:
>
> /**
>* struct foo - struct documentation
>*/
> struct foo {
> /** @bar: member documentation */
> int bar;
> };
Looks good, applied
On Tue, 8 Nov 2016 06:27:08 -0200
Mauro Carvalho Chehab wrote:
> 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
Gee, this i
Em Wed, 16 Nov 2016 15:32:52 -0700
Jonathan Corbet escreveu:
> On Mon, 14 Nov 2016 14:32:32 -0200
> Mauro Carvalho Chehab wrote:
>
> One nit...
>
> > diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
> > index a7fb35291f6c..297b85c37ab9 100644
> > --- a/Documentation/med
Em Wed, 16 Nov 2016 16:35:24 -0700
Jonathan Corbet escreveu:
> On Tue, 8 Nov 2016 06:27:08 -0200
> Mauro Carvalho Chehab wrote:
>
> > Provide a man page for parse-headers.pl, describing
> > how to use it.
> >
> > The documentation on ReST format was generated via pod2rst:
> >
> > http://
Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber:
+79139230330 Telegram: +79139230330 Email: prodawez...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
Hi, all
I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
enabled, compare with aarch32 el0 disabled kernel. And bzip
Hi Bamvor,
I'm surprised that you see this much difference from ILP32 patches on SPEC
CPU2006int at all. The SPEC CPU2006 benchmarks spend almost no time in the
kernel syscalls. I can imagine memory, TLB, and cache handling in the kernel
could affect CPU2006 benchmarks. Do ILP32 patches touc
Hi, Maxim
On 2016/11/17 13:02, Maxim Kuvyrkov wrote:
Hi Bamvor,
I'm surprised that you see this much difference from ILP32 patches on SPEC
CPU2006int at all. The SPEC CPU2006 benchmarks spend almost no time in the
kernel syscalls. I can imagine memory, TLB, and cache handling in the kernel
25 matches
Mail list logo
