* [GIT PULL] Documentation fixes for 5.2
From: Jonathan Corbet @ 2019-05-23 14:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-doc, LKML
The following changes since commit
a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://git.lwn.net/linux.git tags/docs-5.2-fixes
for you to fetch changes up to a65fd4f0def56f59822b2c49522d36319bc8da8b:
Documentation: kdump: fix minor typo (2019-05-21 09:31:28 -0600)
----------------------------------------------------------------
A handful of fixes for a docs build problem, along with catching the
spdxcheck.py script up with the current state of affairs.
----------------------------------------------------------------
Cengiz Can (1):
Documentation: kdump: fix minor typo
Randy Dunlap (1):
counter: fix Documentation build error due to incorrect source file name
Sven Eckelmann (2):
scripts/spdxcheck.py: Fix path to deprecated licenses
scripts/spdxcheck.py: Add dual license subdirectory
Documentation/driver-api/generic-counter.rst | 2 +-
Documentation/kdump/kdump.txt | 2 +-
scripts/spdxcheck.py | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Jonathan Corbet @ 2019-05-23 13:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Oleksandr Natalenko, Jani Nikula, linux-doc, linux-kernel,
Markus Heiser
In-Reply-To: <20190523073830.388b4868@coco.lan>
On Thu, 23 May 2019 07:38:30 -0300
Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> It seems that this message is there since 1.8:
>
> https://www.sphinx-doc.org/en/1.8/_modules/sphinx/application.html
...which is strange, since I didn't see it until I built with 2.0. It was
annoying to see a new warning, but I figured we had some time still before
needing to rush out a last-minute fix for that one :)
jon
^ permalink raw reply
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Oleksandr Natalenko @ 2019-05-23 11:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, linux-doc, linux-kernel, Jani Nikula,
Markus Heiser
In-Reply-To: <20190523074545.65642eac@coco.lan>
On Thu, May 23, 2019 at 07:45:45AM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 23 May 2019 11:39:44 +0200
> Oleksandr Natalenko <oleksandr@redhat.com> escreveu:
>
> > Hi.
> >
> > On Wed, May 22, 2019 at 02:50:26PM -0600, Jonathan Corbet wrote:
> > > The Sphinx folks deprecated some interfaces in the 2.0 release; one
> > > immediate result of that is a bunch of warnings that show up when building
> > > with 1.8. These two patches make those warnings go away, but at a cost:
> > >
> > > - It introduces a couple of Sphinx version checks, which are always
> > > ugly, but the alternative would be to stop supporting versions
> > > before 1.7. For now, I think we can carry that cruft.
> > >
> > > - The second patch causes the build to fail horribly on newer
> > > Sphinx installations. The change to switch_source_input() seems
> > > to make the parser much more finicky, increasing warnings and
> > > eventually failing the build altogether. In particular, it will
> > > scream about problems in .rst files that are not included in the
> > > TOC tree at all.
> > >
> > > This version of the patch set fixes up the worst problems (the i915 error
> > > in particular, which breaks the build hard). I've tested it with versions
> > > 1.4, 1.8, and 2.0.
> > >
> > > Given that these problems are already breaking builds on some systems, I
> > > think I may try to sell these changes to Linus for 5.2 still.
> > >
> > > Changes since v1:
> > > - Fix up a couple of logging changes I somehow missed
> > > - Don't save state when using switch_source_input()
> > > - Fix a few build errors
> > > - Add Mauro's sphinx-pre-install improvements
> > >
> > > Jonathan Corbet (7):
> > > doc: Cope with Sphinx logging deprecations
> > > doc: Cope with the deprecation of AutoReporter
> > > docs: fix numaperf.rst and add it to the doc tree
> > > lib/list_sort: fix kerneldoc build error
> > > docs: fix multiple doc build warnings in enumeration.rst
> > > docs/gpu: fix a documentation build break in i915.rst
> > > docs: Fix conf.py for Sphinx 2.0
> > >
> > > Mauro Carvalho Chehab (1):
> > > scripts/sphinx-pre-install: make it handle Sphinx versions
> > >
> > > Documentation/admin-guide/mm/index.rst | 1 +
> > > Documentation/admin-guide/mm/numaperf.rst | 2 +-
> > > Documentation/conf.py | 2 +-
> > > .../firmware-guide/acpi/enumeration.rst | 2 +-
> > > Documentation/gpu/i915.rst | 4 +-
> > > Documentation/sphinx/kerneldoc.py | 44 +++++++---
> > > Documentation/sphinx/kernellog.py | 28 +++++++
> > > Documentation/sphinx/kfigure.py | 40 +++++----
> > > lib/list_sort.c | 3 +-
> > > scripts/sphinx-pre-install | 81 +++++++++++++++++--
> > > 10 files changed, 166 insertions(+), 41 deletions(-)
> > > create mode 100644 Documentation/sphinx/kernellog.py
> > >
> > > --
> > > 2.21.0
> > >
> >
> > Thanks for the efforts. I've run this on top of Linus' tree, and the
> > only sphinx-related deprecation warning I've spotted is this one:
> >
> > /home/onatalen/work/src/linux/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
> > app.override_domain(CDomain)
> >
> > Otherwise, it builds.
> >
>
> Just sent a fix. Could you please test?
>
>
> https://lore.kernel.org/lkml/b38a9fdfdcda49b2c6118072afac564e96406800.1558608217.git.mchehab+samsung@kernel.org/T/#u
Yes, now it's fine. Thanks.
>
> Thanks,
> Mauro
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
^ permalink raw reply
* [PATCH] scripts/sphinx-pre-install: make activate hint smarter
From: Mauro Carvalho Chehab @ 2019-05-23 11:14 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
It is possible that multiple Sphinx virtualenvs are installed
on a given kernel tree. Change the logic to get the latest
version of those, as this is probably what the user wants.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/sphinx-pre-install | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 8c2d1bcf2e02..11239eb29695 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -1,7 +1,7 @@
#!/usr/bin/perl
use strict;
-# Copyright (c) 2017 Mauro Carvalho Chehab <mchehab@kernel.org>
+# Copyright (c) 2017-2019 Mauro Carvalho Chehab <mchehab@kernel.org>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
@@ -15,6 +15,7 @@ use strict;
my $conf = "Documentation/conf.py";
my $requirement_file = "Documentation/sphinx/requirements.txt";
+my $virtenv_prefix = "sphinx_";
#
# Static vars
@@ -28,7 +29,8 @@ my $need_symlink = 0;
my $need_sphinx = 0;
my $rec_sphinx_upgrade = 0;
my $install = "";
-my $virtenv_dir = "sphinx_";
+my $virtenv_dir = "";
+my $min_version;
#
# Command line arguments
@@ -229,7 +231,6 @@ sub get_sphinx_fname()
sub check_sphinx()
{
- my $min_version;
my $rec_version;
my $cur_version;
@@ -255,7 +256,7 @@ sub check_sphinx()
die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
- $virtenv_dir .= $rec_version;
+ $virtenv_dir = $virtenv_prefix . $rec_version;
my $sphinx = get_sphinx_fname();
return if ($sphinx eq "");
@@ -612,18 +613,23 @@ sub check_needs()
which("sphinx-build-3");
}
if ($need_sphinx || $rec_sphinx_upgrade) {
- my $activate = "$virtenv_dir/bin/activate";
- if (-e "$ENV{'PWD'}/$activate") {
+ my $min_activate = "$ENV{'PWD'}/${virtenv_prefix}${min_version}/bin/activate";
+ my @activates = glob "$ENV{'PWD'}/${virtenv_prefix}*/bin/activate";
+
+ @activates = sort {$b cmp $a} @activates;
+
+ if (scalar @activates > 0 && $activates[0] ge $min_activate) {
printf "\nNeed to activate virtualenv with:\n";
- printf "\t. $activate\n";
+ printf "\t. $activates[0]\n";
} else {
+ my $rec_activate = "$virtenv_dir/bin/activate";
my $virtualenv = findprog("virtualenv-3");
$virtualenv = findprog("virtualenv-3.5") if (!$virtualenv);
$virtualenv = findprog("virtualenv") if (!$virtualenv);
$virtualenv = "virtualenv" if (!$virtualenv);
printf "\t$virtualenv $virtenv_dir\n";
- printf "\t. $activate\n";
+ printf "\t. $rec_activate\n";
printf "\tpip install -r $requirement_file\n";
$need++ if (!$rec_sphinx_upgrade);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Mauro Carvalho Chehab @ 2019-05-23 10:45 UTC (permalink / raw)
To: Oleksandr Natalenko
Cc: Jonathan Corbet, linux-doc, linux-kernel, Jani Nikula,
Markus Heiser
In-Reply-To: <20190523093944.mylk5l3ginkpelfi@butterfly.localdomain>
Em Thu, 23 May 2019 11:39:44 +0200
Oleksandr Natalenko <oleksandr@redhat.com> escreveu:
> Hi.
>
> On Wed, May 22, 2019 at 02:50:26PM -0600, Jonathan Corbet wrote:
> > The Sphinx folks deprecated some interfaces in the 2.0 release; one
> > immediate result of that is a bunch of warnings that show up when building
> > with 1.8. These two patches make those warnings go away, but at a cost:
> >
> > - It introduces a couple of Sphinx version checks, which are always
> > ugly, but the alternative would be to stop supporting versions
> > before 1.7. For now, I think we can carry that cruft.
> >
> > - The second patch causes the build to fail horribly on newer
> > Sphinx installations. The change to switch_source_input() seems
> > to make the parser much more finicky, increasing warnings and
> > eventually failing the build altogether. In particular, it will
> > scream about problems in .rst files that are not included in the
> > TOC tree at all.
> >
> > This version of the patch set fixes up the worst problems (the i915 error
> > in particular, which breaks the build hard). I've tested it with versions
> > 1.4, 1.8, and 2.0.
> >
> > Given that these problems are already breaking builds on some systems, I
> > think I may try to sell these changes to Linus for 5.2 still.
> >
> > Changes since v1:
> > - Fix up a couple of logging changes I somehow missed
> > - Don't save state when using switch_source_input()
> > - Fix a few build errors
> > - Add Mauro's sphinx-pre-install improvements
> >
> > Jonathan Corbet (7):
> > doc: Cope with Sphinx logging deprecations
> > doc: Cope with the deprecation of AutoReporter
> > docs: fix numaperf.rst and add it to the doc tree
> > lib/list_sort: fix kerneldoc build error
> > docs: fix multiple doc build warnings in enumeration.rst
> > docs/gpu: fix a documentation build break in i915.rst
> > docs: Fix conf.py for Sphinx 2.0
> >
> > Mauro Carvalho Chehab (1):
> > scripts/sphinx-pre-install: make it handle Sphinx versions
> >
> > Documentation/admin-guide/mm/index.rst | 1 +
> > Documentation/admin-guide/mm/numaperf.rst | 2 +-
> > Documentation/conf.py | 2 +-
> > .../firmware-guide/acpi/enumeration.rst | 2 +-
> > Documentation/gpu/i915.rst | 4 +-
> > Documentation/sphinx/kerneldoc.py | 44 +++++++---
> > Documentation/sphinx/kernellog.py | 28 +++++++
> > Documentation/sphinx/kfigure.py | 40 +++++----
> > lib/list_sort.c | 3 +-
> > scripts/sphinx-pre-install | 81 +++++++++++++++++--
> > 10 files changed, 166 insertions(+), 41 deletions(-)
> > create mode 100644 Documentation/sphinx/kernellog.py
> >
> > --
> > 2.21.0
> >
>
> Thanks for the efforts. I've run this on top of Linus' tree, and the
> only sphinx-related deprecation warning I've spotted is this one:
>
> /home/onatalen/work/src/linux/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
> app.override_domain(CDomain)
>
> Otherwise, it builds.
>
Just sent a fix. Could you please test?
https://lore.kernel.org/lkml/b38a9fdfdcda49b2c6118072afac564e96406800.1558608217.git.mchehab+samsung@kernel.org/T/#u
Thanks,
Mauro
^ permalink raw reply
* [PATCH] docs: cdomain.py: get rid of a warning since version 1.8
From: Mauro Carvalho Chehab @ 2019-05-23 10:43 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
There's a new warning about a deprecation function. Add a
logic at cdomain.py to avoid that.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/sphinx/cdomain.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
index cf13ff3a656c..cbac8e608dc4 100644
--- a/Documentation/sphinx/cdomain.py
+++ b/Documentation/sphinx/cdomain.py
@@ -48,7 +48,10 @@ major, minor, patch = sphinx.version_info[:3]
def setup(app):
- app.override_domain(CDomain)
+ if (major == 1 and minor < 8):
+ app.override_domain(CDomain)
+ else:
+ app.add_domain(CDomain, override=True)
return dict(
version = __version__,
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Mauro Carvalho Chehab @ 2019-05-23 10:38 UTC (permalink / raw)
To: Oleksandr Natalenko
Cc: Jani Nikula, Jonathan Corbet, linux-doc, linux-kernel,
Markus Heiser
In-Reply-To: <20190523101534.cenmf7rexa7gerot@butterfly.localdomain>
Em Thu, 23 May 2019 12:15:34 +0200
Oleksandr Natalenko <oleksandr@redhat.com> escreveu:
> On Thu, May 23, 2019 at 01:13:23PM +0300, Jani Nikula wrote:
> > On Thu, 23 May 2019, Oleksandr Natalenko <oleksandr@redhat.com> wrote:
> > > Thanks for the efforts. I've run this on top of Linus' tree, and the
> > > only sphinx-related deprecation warning I've spotted is this one:
> > >
> > > /home/onatalen/work/src/linux/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
> > > app.override_domain(CDomain)
> > >
> > > Otherwise, it builds.
> >
> > Please share your Sphinx version (sphinx-build --version).
>
> [~]$ sphinx-build --version
> sphinx-build 2.0.1
>
Same here with vanilla 2.0.0 (installed via pip3):
Running Sphinx v2.0.0
/devel/v4l/docs/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
app.override_domain(CDomain)
It seems that this message is there since 1.8:
https://www.sphinx-doc.org/en/1.8/_modules/sphinx/application.html
The fix seems to be trivial: just replace it to:
app.add_domain(domain, override=True)
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Oleksandr Natalenko @ 2019-05-23 10:15 UTC (permalink / raw)
To: Jani Nikula
Cc: Jonathan Corbet, linux-doc, linux-kernel, Markus Heiser,
Mauro Carvalho Chehab
In-Reply-To: <877eah7a2k.fsf@intel.com>
On Thu, May 23, 2019 at 01:13:23PM +0300, Jani Nikula wrote:
> On Thu, 23 May 2019, Oleksandr Natalenko <oleksandr@redhat.com> wrote:
> > Thanks for the efforts. I've run this on top of Linus' tree, and the
> > only sphinx-related deprecation warning I've spotted is this one:
> >
> > /home/onatalen/work/src/linux/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
> > app.override_domain(CDomain)
> >
> > Otherwise, it builds.
>
> Please share your Sphinx version (sphinx-build --version).
[~]$ sphinx-build --version
sphinx-build 2.0.1
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
^ permalink raw reply
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Jani Nikula @ 2019-05-23 10:13 UTC (permalink / raw)
To: Oleksandr Natalenko, Jonathan Corbet
Cc: linux-doc, linux-kernel, Markus Heiser, Mauro Carvalho Chehab
In-Reply-To: <20190523093944.mylk5l3ginkpelfi@butterfly.localdomain>
On Thu, 23 May 2019, Oleksandr Natalenko <oleksandr@redhat.com> wrote:
> Thanks for the efforts. I've run this on top of Linus' tree, and the
> only sphinx-related deprecation warning I've spotted is this one:
>
> /home/onatalen/work/src/linux/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
> app.override_domain(CDomain)
>
> Otherwise, it builds.
Please share your Sphinx version (sphinx-build --version).
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Oleksandr Natalenko @ 2019-05-23 9:39 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Jani Nikula, Markus Heiser,
Mauro Carvalho Chehab
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Hi.
On Wed, May 22, 2019 at 02:50:26PM -0600, Jonathan Corbet wrote:
> The Sphinx folks deprecated some interfaces in the 2.0 release; one
> immediate result of that is a bunch of warnings that show up when building
> with 1.8. These two patches make those warnings go away, but at a cost:
>
> - It introduces a couple of Sphinx version checks, which are always
> ugly, but the alternative would be to stop supporting versions
> before 1.7. For now, I think we can carry that cruft.
>
> - The second patch causes the build to fail horribly on newer
> Sphinx installations. The change to switch_source_input() seems
> to make the parser much more finicky, increasing warnings and
> eventually failing the build altogether. In particular, it will
> scream about problems in .rst files that are not included in the
> TOC tree at all.
>
> This version of the patch set fixes up the worst problems (the i915 error
> in particular, which breaks the build hard). I've tested it with versions
> 1.4, 1.8, and 2.0.
>
> Given that these problems are already breaking builds on some systems, I
> think I may try to sell these changes to Linus for 5.2 still.
>
> Changes since v1:
> - Fix up a couple of logging changes I somehow missed
> - Don't save state when using switch_source_input()
> - Fix a few build errors
> - Add Mauro's sphinx-pre-install improvements
>
> Jonathan Corbet (7):
> doc: Cope with Sphinx logging deprecations
> doc: Cope with the deprecation of AutoReporter
> docs: fix numaperf.rst and add it to the doc tree
> lib/list_sort: fix kerneldoc build error
> docs: fix multiple doc build warnings in enumeration.rst
> docs/gpu: fix a documentation build break in i915.rst
> docs: Fix conf.py for Sphinx 2.0
>
> Mauro Carvalho Chehab (1):
> scripts/sphinx-pre-install: make it handle Sphinx versions
>
> Documentation/admin-guide/mm/index.rst | 1 +
> Documentation/admin-guide/mm/numaperf.rst | 2 +-
> Documentation/conf.py | 2 +-
> .../firmware-guide/acpi/enumeration.rst | 2 +-
> Documentation/gpu/i915.rst | 4 +-
> Documentation/sphinx/kerneldoc.py | 44 +++++++---
> Documentation/sphinx/kernellog.py | 28 +++++++
> Documentation/sphinx/kfigure.py | 40 +++++----
> lib/list_sort.c | 3 +-
> scripts/sphinx-pre-install | 81 +++++++++++++++++--
> 10 files changed, 166 insertions(+), 41 deletions(-)
> create mode 100644 Documentation/sphinx/kernellog.py
>
> --
> 2.21.0
>
Thanks for the efforts. I've run this on top of Linus' tree, and the
only sphinx-related deprecation warning I've spotted is this one:
/home/onatalen/work/src/linux/Documentation/sphinx/cdomain.py:51: RemovedInSphinx30Warning: app.override_domain() is deprecated. Use app.add_domain() with override option instead.
app.override_domain(CDomain)
Otherwise, it builds.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
^ permalink raw reply
* Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
From: Daniel Vetter @ 2019-05-23 8:40 UTC (permalink / raw)
To: Brendan Higgins
Cc: Theodore Ts'o, Frank Rowand, Bird, Timothy, Knut Omang,
Greg KH, Kees Cook, Kieran Bingham, Luis R. Rodriguez,
Rob Herring, Stephen Boyd, Shuah Khan, devicetree, dri-devel,
kunit-dev, Linux Doc Mailing List, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Amir Goldstein,
Dan Carpenter, Dan Williams, Jeff Dike, Joel Stanley,
Julia Lawall, Kevin Hilman, Logan Gunthorpe, Michael Ellerman,
Petr Mladek, Richard Weinberger, David Rientjes, Steven Rostedt,
wfg, Bjorn Helgaas, Daniel Vetter
In-Reply-To: <CAFd5g476Hc+6jL5sV=VJamXCbqGebwHqqN9N9RppQYMCoo052Q@mail.gmail.com>
On Wed, May 22, 2019 at 02:38:48PM -0700, Brendan Higgins wrote:
> +Bjorn Helgaas
>
> On Wed, May 15, 2019 at 12:41 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote:
> > > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins
> > > > <brendanhiggins@google.com> wrote:
> > > > >
> > > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote:
> > > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote:
> > > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> > > > > > > > However, the reply is incorrect. Kselftest in-kernel tests (which
> > > > > > > > is the context here) can be configured as built in instead of as
> > > > > > > > a module, and built in a UML kernel. The UML kernel can boot,
> > > > > > > > running the in-kernel tests before UML attempts to invoke the
> > > > > > > > init process.
> > > > > > >
> > > > > > > Um, Citation needed?
> > > > > > >
> > > > > > > I don't see any evidence for this in the kselftest documentation, nor
> > > > > > > do I see any evidence of this in the kselftest Makefiles.
> > > > > > >
> > > > > > > There exists test modules in the kernel that run before the init
> > > > > > > scripts run --- but that's not strictly speaking part of kselftests,
> > > > > > > and do not have any kind of infrastructure. As noted, the
> > > > > > > kselftests_harness header file fundamentally assumes that you are
> > > > > > > running test code in userspace.
> > > > > >
> > > > > > Yeah I really like the "no userspace required at all" design of kunit,
> > > > > > while still collecting results in a well-defined way (unless the current
> > > > > > self-test that just run when you load the module, with maybe some
> > > > > > kselftest ad-hoc wrapper around to collect the results).
> > > > > >
> > > > > > What I want to do long-term is to run these kernel unit tests as part of
> > > > > > the build-testing, most likely in gitlab (sooner or later, for drm.git
> > > > >
> > > > > Totally! This is part of the reason I have been insisting on a minimum
> > > > > of UML compatibility for all unit tests. If you can suffiently constrain
> > > > > the environment that is required for tests to run in, it makes it much
> > > > > easier not only for a human to run your tests, but it also makes it a
> > > > > lot easier for an automated service to be able to run your tests.
> > > > >
> > > > > I actually have a prototype presubmit already working on my
> > > > > "stable/non-upstream" branch. You can checkout what presubmit results
> > > > > look like here[1][2].
> > > >
> > > > ug gerrit :-)
> > >
> > > Yeah, yeah, I know, but it is a lot easier for me to get a project set
> > > up here using Gerrit, when we already use that for a lot of other
> > > projects.
> > >
> > > Also, Gerrit has gotten a lot better over the last two years or so. Two
> > > years ago, I wouldn't touch it with a ten foot pole. It's not so bad
> > > anymore, at least if you are used to using a web UI to review code.
> >
> > I was somewhat joking, I'm just not used to gerrit ... And seems to indeed
> > be a lot more polished than last time I looked at it seriously.
>
> I mean, it is still not perfect, but I think it has finally gotten to
> the point where I prefer it over reviewing by email for high context
> patches where you don't expect a lot of deep discussion.
>
> Still not great for patches where you want to have a lot of discussion.
>
> > > > > > only ofc). So that people get their pull requests (and patch series, we
> > > > > > have some ideas to tie this into patchwork) automatically tested for this
> > > > >
> > > > > Might that be Snowpatch[3]? I talked to Russell, the creator of Snowpatch,
> > > > > and he seemed pretty open to collaboration.
> > > > >
> > > > > Before I heard about Snowpatch, I had an intern write a translation
> > > > > layer that made Prow (the presubmit service that I used in the prototype
> > > > > above) work with LKML[4].
> > > >
> > > > There's about 3-4 forks/clones of patchwork. snowpatch is one, we have
> > > > a different one on freedesktop.org. It's a bit a mess :-/
>
> I think Snowpatch is an ozlabs project; at least the maintainer works at IBM.
>
> Patchwork originally was a ozlabs project, right?
So there's two patchworks (snowpatch makes the 3rd): the one on
freedesktop is another fork.
> Has any discussion taken place trying to consolidate some of the forks?
Yup, but didn't lead anywhere unfortunately :-/ At least between patchwork
and patchwork-fdo, I think snowpatch happened in parallel and once it was
done it's kinda too late. The trouble is that they all have slightly
different REST api and functionality, so for CI integration you can't just
switch one for the other.
> Presubmit clearly seems like a feature that a number of people want.
>
> > > Oh, I didn't realize that. I found your patchwork instance here[5], but
> > > do you have a place where I can see the changes you have added to
> > > support presubmit?
> >
> > Ok here's a few links. Aside from the usual patch view we've also added a
> > series view:
> >
> > https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated
> >
> > This ties the patches + cover letter together, and it even (tries to at
> > least) track revisions. Here's an example which is currently at revision
> > 9:
> >
> > https://patchwork.freedesktop.org/series/57232/
>
> Oooh, nice! That looks awesome! Looks like you have a number of presubmits too.
We have a pretty big farm of machines that mostly just crunch through
premerge patch series. postmerge is mostly just for statistics (so we can
find the sporadic failures and better characterize them).
> > Below the patch list for each revision we also have the test result list.
> > If you click on the grey bar it'll expand with the summary from CI, the
> > "See full logs" is link to the full results from our CI. This is driven
> > with some REST api from our jenkins.
> >
> > Patchwork also sends out mails for these results.
>
> Nice! There are obviously a lot of other bots on various kernel
> mailing lists. Do you think people would object to sending presubmit
> results to the mailing lists by default?
>
> > Source is on gitlab: https://gitlab.freedesktop.org/patchwork-fdo
>
> Err, looks like you forked from the ozlab's repo a good while ago.
Yeah see above, it's a bit a complicated story. I think there's a total of
3 patchworks now :-/
> Still, this all looks great!
Cheers, Daniel
>
> > > > > I am not married to either approach, but I think between the two of
> > > > > them, most of the initial legwork has been done to make presubmit on
> > > > > LKML a reality.
> > > >
> > > > We do have presubmit CI working already with our freedesktop.org
> > > > patchwork. The missing glue is just tying that into gitlab CI somehow
> > > > (since we want to unify build testing more and make it easier for
> > > > contributors to adjust things).
> > >
> > > I checked out a couple of your projects on your patchwork instance: AMD
> > > X.Org drivers, DRI devel, and Wayland. I saw the tab you added for
> > > tests, but none of them actually had any test results. Can you point me
> > > at one that does?
> >
> > Atm we use the CI stuff only on intel-gfx, with the our gpu CI farm, see
> > links above.
> >
> > Cheers, Daniel
> >
> > >
> > > Cheers!
> > >
> > > [5] https://patchwork.freedesktop.org/
> > >
> > > > > > super basic stuff.
> > > > >
> > > > > I am really excited to hear back on what you think!
> > > > >
> > > > > Cheers!
> > > > >
> > > > > [1] https://kunit-review.googlesource.com/c/linux/+/1509/10#message-7bfa40efb132e15c8388755c273837559911425c
> > > > > [2] https://kunit-review.googlesource.com/c/linux/+/1509/10#message-a6784496eafff442ac98fb068bf1a0f36ee73509
> > > > > [3] https://developer.ibm.com/open/projects/snowpatch/
> > > > > [4] https://kunit.googlesource.com/prow-lkml/
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> Cheers!
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 3/8] docs: fix numaperf.rst and add it to the doc tree
From: Mike Rapoport @ 2019-05-23 5:45 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Jani Nikula, Markus Heiser,
Mauro Carvalho Chehab, Oleksandr Natalenko, Keith Busch
In-Reply-To: <20190522205034.25724-4-corbet@lwn.net>
On Wed, May 22, 2019 at 02:50:29PM -0600, Jonathan Corbet wrote:
> Commit 13bac55ef7ae ("doc/mm: New documentation for memory performance")
> added numaperf.rst, but did not add it to the TOC tree. There was also an
> incorrectly marked literal block leading to this warning sequence:
>
> numaperf.rst:24: WARNING: Unexpected indentation.
> numaperf.rst:24: WARNING: Inline substitution_reference start-string without end-string.
> numaperf.rst:25: WARNING: Block quote ends without a blank line; unexpected unindent.
>
> Fix the block and add the file to the document tree.
>
> Fixes: 13bac55ef7ae ("doc/mm: New documentation for memory performance")
> Cc: Keith Busch <keith.busch@intel.com>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> Documentation/admin-guide/mm/index.rst | 1 +
> Documentation/admin-guide/mm/numaperf.rst | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst
> index 8edb35f11317..ddf8d8d33377 100644
> --- a/Documentation/admin-guide/mm/index.rst
> +++ b/Documentation/admin-guide/mm/index.rst
> @@ -31,6 +31,7 @@ the Linux memory management.
> ksm
> memory-hotplug
> numa_memory_policy
> + numaperf
> pagemap
> soft-dirty
> transhuge
> diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
> index b79f70c04397..c067ed145158 100644
> --- a/Documentation/admin-guide/mm/numaperf.rst
> +++ b/Documentation/admin-guide/mm/numaperf.rst
> @@ -15,7 +15,7 @@ characteristics. Some memory may share the same node as a CPU, and others
> are provided as memory only nodes. While memory only nodes do not provide
> CPUs, they may still be local to one or more compute nodes relative to
> other nodes. The following diagram shows one such example of two compute
> -nodes with local memory and a memory only node for each of compute node:
> +nodes with local memory and a memory only node for each of compute node::
>
> +------------------+ +------------------+
> | Compute Node 0 +-----+ Compute Node 1 |
> --
> 2.21.0
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 8/8] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Mauro Carvalho Chehab @ 2019-05-22 21:44 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Jani Nikula, Markus Heiser,
Oleksandr Natalenko
In-Reply-To: <20190522182237.057d2a99@coco.lan>
Em Wed, 22 May 2019 18:22:37 -0300
Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> Em Wed, 22 May 2019 14:50:34 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
>
> > From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> >
> > As we want to switch to a newer Sphinx version in the future,
> > add some version detected logic, checking if the current
> > version meets the requirement and suggesting upgrade it the
> > version is supported but too old.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> > ---
> > scripts/sphinx-pre-install | 81 ++++++++++++++++++++++++++++++++++----
> > 1 file changed, 74 insertions(+), 7 deletions(-)
> >
> > diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> > index f6a5c0bae31e..e667db230d0a 100755
> > --- a/scripts/sphinx-pre-install
> > +++ b/scripts/sphinx-pre-install
> > @@ -13,7 +13,7 @@ use strict;
> > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > # GNU General Public License for more details.
> >
> > -my $virtenv_dir = "sphinx_1.4";
> > +my $conf = "Documentation/conf.py";
> > my $requirement_file = "Documentation/sphinx/requirements.txt";
> >
> > #
> > @@ -26,7 +26,9 @@ my $need = 0;
> > my $optional = 0;
> > my $need_symlink = 0;
> > my $need_sphinx = 0;
> > +my $rec_sphinx_upgrade = 0;
> > my $install = "";
> > +my $virtenv_dir = "sphinx_";
> >
> > #
> > # Command line arguments
> > @@ -201,13 +203,15 @@ sub check_missing_tex($)
> > }
> > }
> >
> > -sub check_sphinx()
> > +sub get_sphinx_fname()
> > {
> > - return if findprog("sphinx-build");
> > + my $fname = "sphinx-build";
> > + return $fname if findprog($fname);
> >
> > - if (findprog("sphinx-build-3")) {
> > + $fname = "sphinx-build-3";
> > + if (findprog($fname)) {
> > $need_symlink = 1;
> > - return;
> > + return $fname;
> > }
> >
> > if ($virtualenv) {
> > @@ -219,6 +223,68 @@ sub check_sphinx()
> > } else {
> > add_package("python-sphinx", 0);
> > }
> > +
> > + return "";
> > +}
> > +
> > +sub check_sphinx()
> > +{
> > + my $min_version;
> > + my $rec_version;
> > + my $cur_version;
> > +
> > + open IN, $conf or die "Can't open $conf";
> > + while (<IN>) {
> > + if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
> > + $min_version=$1;
> > + last;
> > + }
> > + }
> > + close IN;
> > +
> > + die "Can't get needs_sphinx version from $conf" if (!$min_version);
> > +
> > + open IN, $requirement_file or die "Can't open $requirement_file";
> > + while (<IN>) {
> > + if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
> > + $rec_version=$1;
> > + last;
> > + }
> > + }
> > + close IN;
> > +
> > + die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
> > +
> > + my $sphinx = get_sphinx_fname();
> > + return if ($sphinx eq "");
> > +
> > + open IN, "$sphinx --version 2>&1 |" or die "$sphinx returned an error";
> > + while (<IN>) {
> > + if (m/^\s*sphinx-build\s+([\d\.]+)$/) {
> > + $cur_version=$1;
> > + last;
> > + }
> > + }
> > + close IN;
> > +
> > + $virtenv_dir .= $rec_version;
> > +
> > + die "$sphinx didn't return its version" if (!$cur_version);
> > +
> > + printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
> > + $cur_version, $min_version, $rec_version;
> > +
> > + if ($cur_version lt $min_version) {
> > + print "Warning: Sphinx version should be >= $min_version\n\n";
> > + $need_sphinx = 1;
> > + return;
> > + }
> > +
> > + if ($cur_version lt $rec_version) {
> > + print "Warning: It is recommended at least Sphinx version $rec_version.\n";
> > + print " To upgrade, use:\n\n";
> > + $rec_sphinx_upgrade = 1;
> > + }
> > }
> >
> > #
> > @@ -540,7 +606,7 @@ sub check_needs()
> > printf "\tsudo ln -sf %s /usr/bin/sphinx-build\n\n",
> > which("sphinx-build-3");
> > }
> > - if ($need_sphinx) {
> > + if ($need_sphinx || $rec_sphinx_upgrade) {
> > my $activate = "$virtenv_dir/bin/activate";
> > if (-e "$ENV{'PWD'}/$activate") {
> > printf "\nNeed to activate virtualenv with:\n";
> > @@ -554,7 +620,8 @@ sub check_needs()
> > printf "\t$virtualenv $virtenv_dir\n";
> > printf "\t. $activate\n";
> > printf "\tpip install -r $requirement_file\n";
> > - $need++;
> > +
> > + $need++ if (!$rec_sphinx_upgrade);
> > }
> > }
> > printf "\n";
>
> Please fold this to the patch:
>
> diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> index e667db230d0a..45427f4289ed 100755
> --- a/scripts/sphinx-pre-install
> +++ b/scripts/sphinx-pre-install
> @@ -255,6 +255,8 @@ sub check_sphinx()
>
> die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
>
> + $virtenv_dir .= $rec_version;
> +
> my $sphinx = get_sphinx_fname();
> return if ($sphinx eq "");
>
> @@ -267,8 +269,6 @@ sub check_sphinx()
> }
> close IN;
>
> - $virtenv_dir .= $rec_version;
> -
> die "$sphinx didn't return its version" if (!$cur_version);
>
> printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
>
>
> Thanks,
> Mauro
Found another issue when trying to run it with Sphinx 1.2. Just sent
a version 2 with this fix, plus the version detection for very old
Sphinx versions.
Thanks,
Mauro
^ permalink raw reply
* [PATCH v2] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Mauro Carvalho Chehab @ 2019-05-22 21:43 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
As we want to switch to a newer Sphinx version in the future,
add some version detected logic, checking if the current
version meets the requirement and suggesting upgrade it the
version is supported but too old.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/sphinx-pre-install | 86 ++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index f6a5c0bae31e..8c2d1bcf2e02 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -13,7 +13,7 @@ use strict;
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-my $virtenv_dir = "sphinx_1.4";
+my $conf = "Documentation/conf.py";
my $requirement_file = "Documentation/sphinx/requirements.txt";
#
@@ -26,7 +26,9 @@ my $need = 0;
my $optional = 0;
my $need_symlink = 0;
my $need_sphinx = 0;
+my $rec_sphinx_upgrade = 0;
my $install = "";
+my $virtenv_dir = "sphinx_";
#
# Command line arguments
@@ -201,13 +203,15 @@ sub check_missing_tex($)
}
}
-sub check_sphinx()
+sub get_sphinx_fname()
{
- return if findprog("sphinx-build");
+ my $fname = "sphinx-build";
+ return $fname if findprog($fname);
- if (findprog("sphinx-build-3")) {
+ $fname = "sphinx-build-3";
+ if (findprog($fname)) {
$need_symlink = 1;
- return;
+ return $fname;
}
if ($virtualenv) {
@@ -219,6 +223,73 @@ sub check_sphinx()
} else {
add_package("python-sphinx", 0);
}
+
+ return "";
+}
+
+sub check_sphinx()
+{
+ my $min_version;
+ my $rec_version;
+ my $cur_version;
+
+ open IN, $conf or die "Can't open $conf";
+ while (<IN>) {
+ if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
+ $min_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get needs_sphinx version from $conf" if (!$min_version);
+
+ open IN, $requirement_file or die "Can't open $requirement_file";
+ while (<IN>) {
+ if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
+ $rec_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
+
+ $virtenv_dir .= $rec_version;
+
+ my $sphinx = get_sphinx_fname();
+ return if ($sphinx eq "");
+
+ open IN, "$sphinx --version 2>&1 |" or die "$sphinx returned an error";
+ while (<IN>) {
+ if (m/^\s*sphinx-build\s+([\d\.]+)$/) {
+ $cur_version=$1;
+ last;
+ }
+ # Sphinx 1.2.x uses a different format
+ if (m/^\s*Sphinx.*\s+([\d\.]+)$/) {
+ $cur_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "$sphinx didn't return its version" if (!$cur_version);
+
+ printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
+ $cur_version, $min_version, $rec_version;
+
+ if ($cur_version lt $min_version) {
+ print "Warning: Sphinx version should be >= $min_version\n\n";
+ $need_sphinx = 1;
+ return;
+ }
+
+ if ($cur_version lt $rec_version) {
+ print "Warning: It is recommended at least Sphinx version $rec_version.\n";
+ print " To upgrade, use:\n\n";
+ $rec_sphinx_upgrade = 1;
+ }
}
#
@@ -540,7 +611,7 @@ sub check_needs()
printf "\tsudo ln -sf %s /usr/bin/sphinx-build\n\n",
which("sphinx-build-3");
}
- if ($need_sphinx) {
+ if ($need_sphinx || $rec_sphinx_upgrade) {
my $activate = "$virtenv_dir/bin/activate";
if (-e "$ENV{'PWD'}/$activate") {
printf "\nNeed to activate virtualenv with:\n";
@@ -554,7 +625,8 @@ sub check_needs()
printf "\t$virtualenv $virtenv_dir\n";
printf "\t. $activate\n";
printf "\tpip install -r $requirement_file\n";
- $need++;
+
+ $need++ if (!$rec_sphinx_upgrade);
}
}
printf "\n";
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
From: Brendan Higgins @ 2019-05-22 21:38 UTC (permalink / raw)
To: Brendan Higgins, Theodore Ts'o, Frank Rowand, Bird, Timothy,
Knut Omang, Greg KH, Kees Cook, Kieran Bingham, Luis R. Rodriguez,
Rob Herring, Stephen Boyd, Shuah Khan, devicetree, dri-devel,
kunit-dev, Linux Doc Mailing List, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Amir Goldstein,
Dan Carpenter, Dan Williams, Jeff Dike, Joel Stanley,
Julia Lawall, Kevin Hilman, Logan Gunthorpe, Michael Ellerman,
Petr Mladek, Richard Weinberger, David Rientjes, Steven Rostedt,
wfg, Bjorn Helgaas
Cc: Daniel Vetter
In-Reply-To: <20190515074141.GY17751@phenom.ffwll.local>
+Bjorn Helgaas
On Wed, May 15, 2019 at 12:41 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote:
> > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote:
> > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins
> > > <brendanhiggins@google.com> wrote:
> > > >
> > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote:
> > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote:
> > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> > > > > > > However, the reply is incorrect. Kselftest in-kernel tests (which
> > > > > > > is the context here) can be configured as built in instead of as
> > > > > > > a module, and built in a UML kernel. The UML kernel can boot,
> > > > > > > running the in-kernel tests before UML attempts to invoke the
> > > > > > > init process.
> > > > > >
> > > > > > Um, Citation needed?
> > > > > >
> > > > > > I don't see any evidence for this in the kselftest documentation, nor
> > > > > > do I see any evidence of this in the kselftest Makefiles.
> > > > > >
> > > > > > There exists test modules in the kernel that run before the init
> > > > > > scripts run --- but that's not strictly speaking part of kselftests,
> > > > > > and do not have any kind of infrastructure. As noted, the
> > > > > > kselftests_harness header file fundamentally assumes that you are
> > > > > > running test code in userspace.
> > > > >
> > > > > Yeah I really like the "no userspace required at all" design of kunit,
> > > > > while still collecting results in a well-defined way (unless the current
> > > > > self-test that just run when you load the module, with maybe some
> > > > > kselftest ad-hoc wrapper around to collect the results).
> > > > >
> > > > > What I want to do long-term is to run these kernel unit tests as part of
> > > > > the build-testing, most likely in gitlab (sooner or later, for drm.git
> > > >
> > > > Totally! This is part of the reason I have been insisting on a minimum
> > > > of UML compatibility for all unit tests. If you can suffiently constrain
> > > > the environment that is required for tests to run in, it makes it much
> > > > easier not only for a human to run your tests, but it also makes it a
> > > > lot easier for an automated service to be able to run your tests.
> > > >
> > > > I actually have a prototype presubmit already working on my
> > > > "stable/non-upstream" branch. You can checkout what presubmit results
> > > > look like here[1][2].
> > >
> > > ug gerrit :-)
> >
> > Yeah, yeah, I know, but it is a lot easier for me to get a project set
> > up here using Gerrit, when we already use that for a lot of other
> > projects.
> >
> > Also, Gerrit has gotten a lot better over the last two years or so. Two
> > years ago, I wouldn't touch it with a ten foot pole. It's not so bad
> > anymore, at least if you are used to using a web UI to review code.
>
> I was somewhat joking, I'm just not used to gerrit ... And seems to indeed
> be a lot more polished than last time I looked at it seriously.
I mean, it is still not perfect, but I think it has finally gotten to
the point where I prefer it over reviewing by email for high context
patches where you don't expect a lot of deep discussion.
Still not great for patches where you want to have a lot of discussion.
> > > > > only ofc). So that people get their pull requests (and patch series, we
> > > > > have some ideas to tie this into patchwork) automatically tested for this
> > > >
> > > > Might that be Snowpatch[3]? I talked to Russell, the creator of Snowpatch,
> > > > and he seemed pretty open to collaboration.
> > > >
> > > > Before I heard about Snowpatch, I had an intern write a translation
> > > > layer that made Prow (the presubmit service that I used in the prototype
> > > > above) work with LKML[4].
> > >
> > > There's about 3-4 forks/clones of patchwork. snowpatch is one, we have
> > > a different one on freedesktop.org. It's a bit a mess :-/
I think Snowpatch is an ozlabs project; at least the maintainer works at IBM.
Patchwork originally was a ozlabs project, right?
Has any discussion taken place trying to consolidate some of the forks?
Presubmit clearly seems like a feature that a number of people want.
> > Oh, I didn't realize that. I found your patchwork instance here[5], but
> > do you have a place where I can see the changes you have added to
> > support presubmit?
>
> Ok here's a few links. Aside from the usual patch view we've also added a
> series view:
>
> https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated
>
> This ties the patches + cover letter together, and it even (tries to at
> least) track revisions. Here's an example which is currently at revision
> 9:
>
> https://patchwork.freedesktop.org/series/57232/
Oooh, nice! That looks awesome! Looks like you have a number of presubmits too.
> Below the patch list for each revision we also have the test result list.
> If you click on the grey bar it'll expand with the summary from CI, the
> "See full logs" is link to the full results from our CI. This is driven
> with some REST api from our jenkins.
>
> Patchwork also sends out mails for these results.
Nice! There are obviously a lot of other bots on various kernel
mailing lists. Do you think people would object to sending presubmit
results to the mailing lists by default?
> Source is on gitlab: https://gitlab.freedesktop.org/patchwork-fdo
Err, looks like you forked from the ozlab's repo a good while ago.
Still, this all looks great!
> > > > I am not married to either approach, but I think between the two of
> > > > them, most of the initial legwork has been done to make presubmit on
> > > > LKML a reality.
> > >
> > > We do have presubmit CI working already with our freedesktop.org
> > > patchwork. The missing glue is just tying that into gitlab CI somehow
> > > (since we want to unify build testing more and make it easier for
> > > contributors to adjust things).
> >
> > I checked out a couple of your projects on your patchwork instance: AMD
> > X.Org drivers, DRI devel, and Wayland. I saw the tab you added for
> > tests, but none of them actually had any test results. Can you point me
> > at one that does?
>
> Atm we use the CI stuff only on intel-gfx, with the our gpu CI farm, see
> links above.
>
> Cheers, Daniel
>
> >
> > Cheers!
> >
> > [5] https://patchwork.freedesktop.org/
> >
> > > > > super basic stuff.
> > > >
> > > > I am really excited to hear back on what you think!
> > > >
> > > > Cheers!
> > > >
> > > > [1] https://kunit-review.googlesource.com/c/linux/+/1509/10#message-7bfa40efb132e15c8388755c273837559911425c
> > > > [2] https://kunit-review.googlesource.com/c/linux/+/1509/10#message-a6784496eafff442ac98fb068bf1a0f36ee73509
> > > > [3] https://developer.ibm.com/open/projects/snowpatch/
> > > > [4] https://kunit.googlesource.com/prow-lkml/
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Cheers!
^ permalink raw reply
* Re: [PATCH] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Mauro Carvalho Chehab @ 2019-05-22 21:35 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Markus Heiser, Jani Nikula, linux-doc, linux-kernel
In-Reply-To: <20190522143506.34049678@lwn.net>
Em Wed, 22 May 2019 14:35:06 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 22 May 2019 13:28:34 -0400
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > As we want to switch to a newer Sphinx version in the future,
> > add some version detected logic, checking if the current
> > version meets the requirement and suggesting upgrade it the
> > version is supported but too old.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> I've applied this in the branch with my other fixes (coming soon to a
> mailing list near you), thanks. I do think we eventually want to emit a
> warning during a normal docs build as well, and to raise the recommended
> version, but one step at a time...
The enclosed patch should do the work. It will probably be too verbose, but
it should be easy to add a "--silent" parameter to the script, making it
only display a message with the version warning.
Thanks,
Mauro
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e889e7cb8511..9c80105995e7 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -70,6 +70,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
$(abspath $(BUILDDIR)/$3/$4)
htmldocs:
+ @./scripts/sphinx-pre-install
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var)))
linkcheckdocs:
^ permalink raw reply related
* Re: [PATCH 8/8] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Mauro Carvalho Chehab @ 2019-05-22 21:22 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Jani Nikula, Markus Heiser,
Oleksandr Natalenko, Mauro Carvalho Chehab
In-Reply-To: <20190522205034.25724-9-corbet@lwn.net>
Em Wed, 22 May 2019 14:50:34 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> As we want to switch to a newer Sphinx version in the future,
> add some version detected logic, checking if the current
> version meets the requirement and suggesting upgrade it the
> version is supported but too old.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> ---
> scripts/sphinx-pre-install | 81 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 74 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
> index f6a5c0bae31e..e667db230d0a 100755
> --- a/scripts/sphinx-pre-install
> +++ b/scripts/sphinx-pre-install
> @@ -13,7 +13,7 @@ use strict;
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> # GNU General Public License for more details.
>
> -my $virtenv_dir = "sphinx_1.4";
> +my $conf = "Documentation/conf.py";
> my $requirement_file = "Documentation/sphinx/requirements.txt";
>
> #
> @@ -26,7 +26,9 @@ my $need = 0;
> my $optional = 0;
> my $need_symlink = 0;
> my $need_sphinx = 0;
> +my $rec_sphinx_upgrade = 0;
> my $install = "";
> +my $virtenv_dir = "sphinx_";
>
> #
> # Command line arguments
> @@ -201,13 +203,15 @@ sub check_missing_tex($)
> }
> }
>
> -sub check_sphinx()
> +sub get_sphinx_fname()
> {
> - return if findprog("sphinx-build");
> + my $fname = "sphinx-build";
> + return $fname if findprog($fname);
>
> - if (findprog("sphinx-build-3")) {
> + $fname = "sphinx-build-3";
> + if (findprog($fname)) {
> $need_symlink = 1;
> - return;
> + return $fname;
> }
>
> if ($virtualenv) {
> @@ -219,6 +223,68 @@ sub check_sphinx()
> } else {
> add_package("python-sphinx", 0);
> }
> +
> + return "";
> +}
> +
> +sub check_sphinx()
> +{
> + my $min_version;
> + my $rec_version;
> + my $cur_version;
> +
> + open IN, $conf or die "Can't open $conf";
> + while (<IN>) {
> + if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
> + $min_version=$1;
> + last;
> + }
> + }
> + close IN;
> +
> + die "Can't get needs_sphinx version from $conf" if (!$min_version);
> +
> + open IN, $requirement_file or die "Can't open $requirement_file";
> + while (<IN>) {
> + if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
> + $rec_version=$1;
> + last;
> + }
> + }
> + close IN;
> +
> + die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
> +
> + my $sphinx = get_sphinx_fname();
> + return if ($sphinx eq "");
> +
> + open IN, "$sphinx --version 2>&1 |" or die "$sphinx returned an error";
> + while (<IN>) {
> + if (m/^\s*sphinx-build\s+([\d\.]+)$/) {
> + $cur_version=$1;
> + last;
> + }
> + }
> + close IN;
> +
> + $virtenv_dir .= $rec_version;
> +
> + die "$sphinx didn't return its version" if (!$cur_version);
> +
> + printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
> + $cur_version, $min_version, $rec_version;
> +
> + if ($cur_version lt $min_version) {
> + print "Warning: Sphinx version should be >= $min_version\n\n";
> + $need_sphinx = 1;
> + return;
> + }
> +
> + if ($cur_version lt $rec_version) {
> + print "Warning: It is recommended at least Sphinx version $rec_version.\n";
> + print " To upgrade, use:\n\n";
> + $rec_sphinx_upgrade = 1;
> + }
> }
>
> #
> @@ -540,7 +606,7 @@ sub check_needs()
> printf "\tsudo ln -sf %s /usr/bin/sphinx-build\n\n",
> which("sphinx-build-3");
> }
> - if ($need_sphinx) {
> + if ($need_sphinx || $rec_sphinx_upgrade) {
> my $activate = "$virtenv_dir/bin/activate";
> if (-e "$ENV{'PWD'}/$activate") {
> printf "\nNeed to activate virtualenv with:\n";
> @@ -554,7 +620,8 @@ sub check_needs()
> printf "\t$virtualenv $virtenv_dir\n";
> printf "\t. $activate\n";
> printf "\tpip install -r $requirement_file\n";
> - $need++;
> +
> + $need++ if (!$rec_sphinx_upgrade);
> }
> }
> printf "\n";
Please fold this to the patch:
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index e667db230d0a..45427f4289ed 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -255,6 +255,8 @@ sub check_sphinx()
die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
+ $virtenv_dir .= $rec_version;
+
my $sphinx = get_sphinx_fname();
return if ($sphinx eq "");
@@ -267,8 +269,6 @@ sub check_sphinx()
}
close IN;
- $virtenv_dir .= $rec_version;
-
die "$sphinx didn't return its version" if (!$cur_version);
printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
Thanks,
Mauro
^ permalink raw reply related
* [PATCH 1/8] doc: Cope with Sphinx logging deprecations
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Recent versions of sphinx will emit messages like:
/stuff/k/git/kernel/Documentation/sphinx/kerneldoc.py:103:
RemovedInSphinx20Warning: app.warning() is now deprecated.
Use sphinx.util.logging instead.
Switch to sphinx.util.logging to make this unsightly message go away.
Alas, that interface was only added in version 1.6, so we have to add a
version check to keep things working with older sphinxes.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/sphinx/kerneldoc.py | 12 ++++++----
Documentation/sphinx/kernellog.py | 28 ++++++++++++++++++++++
Documentation/sphinx/kfigure.py | 40 ++++++++++++++++++-------------
3 files changed, 59 insertions(+), 21 deletions(-)
create mode 100644 Documentation/sphinx/kernellog.py
diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py
index 9d0a7f08f93b..200c8aa4a04f 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -39,6 +39,8 @@ from docutils.statemachine import ViewList
from docutils.parsers.rst import directives, Directive
from sphinx.ext.autodoc import AutodocReporter
+import kernellog
+
__version__ = '1.0'
class KernelDocDirective(Directive):
@@ -90,7 +92,8 @@ class KernelDocDirective(Directive):
cmd += [filename]
try:
- env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
+ kernellog.verbose(env.app,
+ 'calling kernel-doc \'%s\'' % (" ".join(cmd)))
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
out, err = p.communicate()
@@ -100,7 +103,8 @@ class KernelDocDirective(Directive):
if p.returncode != 0:
sys.stderr.write(err)
- env.app.warn('kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
+ kernellog.warn(env.app,
+ 'kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
elif env.config.kerneldoc_verbosity > 0:
sys.stderr.write(err)
@@ -132,8 +136,8 @@ class KernelDocDirective(Directive):
return node.children
except Exception as e: # pylint: disable=W0703
- env.app.warn('kernel-doc \'%s\' processing failed with: %s' %
- (" ".join(cmd), str(e)))
+ kernellog.warn(env.app, 'kernel-doc \'%s\' processing failed with: %s' %
+ (" ".join(cmd), str(e)))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
def setup(app):
diff --git a/Documentation/sphinx/kernellog.py b/Documentation/sphinx/kernellog.py
new file mode 100644
index 000000000000..af924f51a7dc
--- /dev/null
+++ b/Documentation/sphinx/kernellog.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Sphinx has deprecated its older logging interface, but the replacement
+# only goes back to 1.6. So here's a wrapper layer to keep around for
+# as long as we support 1.4.
+#
+import sphinx
+
+if sphinx.__version__[:3] >= '1.6':
+ UseLogging = True
+ from sphinx.util import logging
+ logger = logging.getLogger('kerneldoc')
+else:
+ UseLogging = False
+
+def warn(app, message):
+ if UseLogging:
+ logger.warning(message)
+ else:
+ app.warn(message)
+
+def verbose(app, message):
+ if UseLogging:
+ logger.verbose(message)
+ else:
+ app.verbose(message)
+
+
diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py
index b97228d2cc0e..fbfe6693bb60 100644
--- a/Documentation/sphinx/kfigure.py
+++ b/Documentation/sphinx/kfigure.py
@@ -60,6 +60,8 @@ import sphinx
from sphinx.util.nodes import clean_astext
from six import iteritems
+import kernellog
+
PY3 = sys.version_info[0] == 3
if PY3:
@@ -171,20 +173,20 @@ def setupTools(app):
This function is called once, when the builder is initiated.
"""
global dot_cmd, convert_cmd # pylint: disable=W0603
- app.verbose("kfigure: check installed tools ...")
+ kernellog.verbose(app, "kfigure: check installed tools ...")
dot_cmd = which('dot')
convert_cmd = which('convert')
if dot_cmd:
- app.verbose("use dot(1) from: " + dot_cmd)
+ kernellog.verbose(app, "use dot(1) from: " + dot_cmd)
else:
- app.warn("dot(1) not found, for better output quality install "
- "graphviz from http://www.graphviz.org")
+ kernellog.warn(app, "dot(1) not found, for better output quality install "
+ "graphviz from http://www.graphviz.org")
if convert_cmd:
- app.verbose("use convert(1) from: " + convert_cmd)
+ kernellog.verbose(app, "use convert(1) from: " + convert_cmd)
else:
- app.warn(
+ kernellog.warn(app,
"convert(1) not found, for SVG to PDF conversion install "
"ImageMagick (https://www.imagemagick.org)")
@@ -220,12 +222,13 @@ def convert_image(img_node, translator, src_fname=None):
# in kernel builds, use 'make SPHINXOPTS=-v' to see verbose messages
- app.verbose('assert best format for: ' + img_node['uri'])
+ kernellog.verbose(app, 'assert best format for: ' + img_node['uri'])
if in_ext == '.dot':
if not dot_cmd:
- app.verbose("dot from graphviz not available / include DOT raw.")
+ kernellog.verbose(app,
+ "dot from graphviz not available / include DOT raw.")
img_node.replace_self(file2literal(src_fname))
elif translator.builder.format == 'latex':
@@ -252,7 +255,8 @@ def convert_image(img_node, translator, src_fname=None):
if translator.builder.format == 'latex':
if convert_cmd is None:
- app.verbose("no SVG to PDF conversion available / include SVG raw.")
+ kernellog.verbose(app,
+ "no SVG to PDF conversion available / include SVG raw.")
img_node.replace_self(file2literal(src_fname))
else:
dst_fname = path.join(translator.builder.outdir, fname + '.pdf')
@@ -265,18 +269,19 @@ def convert_image(img_node, translator, src_fname=None):
_name = dst_fname[len(translator.builder.outdir) + 1:]
if isNewer(dst_fname, src_fname):
- app.verbose("convert: {out}/%s already exists and is newer" % _name)
+ kernellog.verbose(app,
+ "convert: {out}/%s already exists and is newer" % _name)
else:
ok = False
mkdir(path.dirname(dst_fname))
if in_ext == '.dot':
- app.verbose('convert DOT to: {out}/' + _name)
+ kernellog.verbose(app, 'convert DOT to: {out}/' + _name)
ok = dot2format(app, src_fname, dst_fname)
elif in_ext == '.svg':
- app.verbose('convert SVG to: {out}/' + _name)
+ kernellog.verbose(app, 'convert SVG to: {out}/' + _name)
ok = svg2pdf(app, src_fname, dst_fname)
if not ok:
@@ -305,7 +310,8 @@ def dot2format(app, dot_fname, out_fname):
with open(out_fname, "w") as out:
exit_code = subprocess.call(cmd, stdout = out)
if exit_code != 0:
- app.warn("Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
+ kernellog.warn(app,
+ "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
return bool(exit_code == 0)
def svg2pdf(app, svg_fname, pdf_fname):
@@ -322,7 +328,7 @@ def svg2pdf(app, svg_fname, pdf_fname):
# use stdout and stderr from parent
exit_code = subprocess.call(cmd)
if exit_code != 0:
- app.warn("Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
+ kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
return bool(exit_code == 0)
@@ -415,15 +421,15 @@ def visit_kernel_render(self, node):
app = self.builder.app
srclang = node.get('srclang')
- app.verbose('visit kernel-render node lang: "%s"' % (srclang))
+ kernellog.verbose(app, 'visit kernel-render node lang: "%s"' % (srclang))
tmp_ext = RENDER_MARKUP_EXT.get(srclang, None)
if tmp_ext is None:
- app.warn('kernel-render: "%s" unknown / include raw.' % (srclang))
+ kernellog.warn(app, 'kernel-render: "%s" unknown / include raw.' % (srclang))
return
if not dot_cmd and tmp_ext == '.dot':
- app.verbose("dot from graphviz not available / include raw.")
+ kernellog.verbose(app, "dot from graphviz not available / include raw.")
return
literal_block = node[0]
--
2.21.0
^ permalink raw reply related
* [PATCH 3/8] docs: fix numaperf.rst and add it to the doc tree
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet, Keith Busch, Mike Rapoport
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Commit 13bac55ef7ae ("doc/mm: New documentation for memory performance")
added numaperf.rst, but did not add it to the TOC tree. There was also an
incorrectly marked literal block leading to this warning sequence:
numaperf.rst:24: WARNING: Unexpected indentation.
numaperf.rst:24: WARNING: Inline substitution_reference start-string without end-string.
numaperf.rst:25: WARNING: Block quote ends without a blank line; unexpected unindent.
Fix the block and add the file to the document tree.
Fixes: 13bac55ef7ae ("doc/mm: New documentation for memory performance")
Cc: Keith Busch <keith.busch@intel.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/admin-guide/mm/index.rst | 1 +
Documentation/admin-guide/mm/numaperf.rst | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst
index 8edb35f11317..ddf8d8d33377 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -31,6 +31,7 @@ the Linux memory management.
ksm
memory-hotplug
numa_memory_policy
+ numaperf
pagemap
soft-dirty
transhuge
diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
index b79f70c04397..c067ed145158 100644
--- a/Documentation/admin-guide/mm/numaperf.rst
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -15,7 +15,7 @@ characteristics. Some memory may share the same node as a CPU, and others
are provided as memory only nodes. While memory only nodes do not provide
CPUs, they may still be local to one or more compute nodes relative to
other nodes. The following diagram shows one such example of two compute
-nodes with local memory and a memory only node for each of compute node:
+nodes with local memory and a memory only node for each of compute node::
+------------------+ +------------------+
| Compute Node 0 +-----+ Compute Node 1 |
--
2.21.0
^ permalink raw reply related
* [PATCH 2/8] doc: Cope with the deprecation of AutoReporter
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
AutoReporter is going away; recent versions of sphinx emit a warning like:
/stuff/k/git/kernel/Documentation/sphinx/kerneldoc.py:125:
RemovedInSphinx20Warning: AutodocReporter is now deprecated.
Use sphinx.util.docutils.switch_source_input() instead.
Make the switch. But switch_source_input() only showed up in 1.7, so we
have to do ugly version checks to keep things working in older versions.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/sphinx/kerneldoc.py | 34 +++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py
index 200c8aa4a04f..1159405cb920 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -37,7 +37,17 @@ import glob
from docutils import nodes, statemachine
from docutils.statemachine import ViewList
from docutils.parsers.rst import directives, Directive
-from sphinx.ext.autodoc import AutodocReporter
+
+#
+# AutodocReporter is only good up to Sphinx 1.7
+#
+import sphinx
+
+Use_SSI = sphinx.__version__[:3] >= '1.7'
+if Use_SSI:
+ from sphinx.util.docutils import switch_source_input
+else:
+ from sphinx.ext.autodoc import AutodocReporter
import kernellog
@@ -125,13 +135,7 @@ class KernelDocDirective(Directive):
lineoffset += 1
node = nodes.section()
- buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
- self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
- self.state.memo.title_styles, self.state.memo.section_level = [], 0
- try:
- self.state.nested_parse(result, 0, node, match_titles=1)
- finally:
- self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
+ self.do_parse(result, node)
return node.children
@@ -140,6 +144,20 @@ class KernelDocDirective(Directive):
(" ".join(cmd), str(e)))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
+ def do_parse(self, result, node):
+ if Use_SSI:
+ with switch_source_input(self.state, result):
+ self.state.nested_parse(result, 0, node, match_titles=1)
+ else:
+ save = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
+ self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
+ self.state.memo.title_styles, self.state.memo.section_level = [], 0
+ try:
+ self.state.nested_parse(result, 0, node, match_titles=1)
+ finally:
+ self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = save
+
+
def setup(app):
app.add_config_value('kerneldoc_bin', None, 'env')
app.add_config_value('kerneldoc_srctree', None, 'env')
--
2.21.0
^ permalink raw reply related
* [PATCH 7/8] docs: Fix conf.py for Sphinx 2.0
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Our version check in Documentation/conf.py never envisioned a world where
Sphinx moved beyond 1.x. Now that the unthinkable has happened, fix our
version check to handle higher version numbers correctly.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/conf.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 72647a38b5c2..7ace3f8852bd 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -37,7 +37,7 @@ needs_sphinx = '1.3'
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
# The name of the math extension changed on Sphinx 1.4
-if major == 1 and minor > 3:
+if (major == 1 and minor > 3) or (major > 1):
extensions.append("sphinx.ext.imgmath")
else:
extensions.append("sphinx.ext.pngmath")
--
2.21.0
^ permalink raw reply related
* [PATCH 8/8] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Mauro Carvalho Chehab, Jonathan Corbet
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
As we want to switch to a newer Sphinx version in the future,
add some version detected logic, checking if the current
version meets the requirement and suggesting upgrade it the
version is supported but too old.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
scripts/sphinx-pre-install | 81 ++++++++++++++++++++++++++++++++++----
1 file changed, 74 insertions(+), 7 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index f6a5c0bae31e..e667db230d0a 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -13,7 +13,7 @@ use strict;
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-my $virtenv_dir = "sphinx_1.4";
+my $conf = "Documentation/conf.py";
my $requirement_file = "Documentation/sphinx/requirements.txt";
#
@@ -26,7 +26,9 @@ my $need = 0;
my $optional = 0;
my $need_symlink = 0;
my $need_sphinx = 0;
+my $rec_sphinx_upgrade = 0;
my $install = "";
+my $virtenv_dir = "sphinx_";
#
# Command line arguments
@@ -201,13 +203,15 @@ sub check_missing_tex($)
}
}
-sub check_sphinx()
+sub get_sphinx_fname()
{
- return if findprog("sphinx-build");
+ my $fname = "sphinx-build";
+ return $fname if findprog($fname);
- if (findprog("sphinx-build-3")) {
+ $fname = "sphinx-build-3";
+ if (findprog($fname)) {
$need_symlink = 1;
- return;
+ return $fname;
}
if ($virtualenv) {
@@ -219,6 +223,68 @@ sub check_sphinx()
} else {
add_package("python-sphinx", 0);
}
+
+ return "";
+}
+
+sub check_sphinx()
+{
+ my $min_version;
+ my $rec_version;
+ my $cur_version;
+
+ open IN, $conf or die "Can't open $conf";
+ while (<IN>) {
+ if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
+ $min_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get needs_sphinx version from $conf" if (!$min_version);
+
+ open IN, $requirement_file or die "Can't open $requirement_file";
+ while (<IN>) {
+ if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
+ $rec_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
+
+ my $sphinx = get_sphinx_fname();
+ return if ($sphinx eq "");
+
+ open IN, "$sphinx --version 2>&1 |" or die "$sphinx returned an error";
+ while (<IN>) {
+ if (m/^\s*sphinx-build\s+([\d\.]+)$/) {
+ $cur_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ $virtenv_dir .= $rec_version;
+
+ die "$sphinx didn't return its version" if (!$cur_version);
+
+ printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
+ $cur_version, $min_version, $rec_version;
+
+ if ($cur_version lt $min_version) {
+ print "Warning: Sphinx version should be >= $min_version\n\n";
+ $need_sphinx = 1;
+ return;
+ }
+
+ if ($cur_version lt $rec_version) {
+ print "Warning: It is recommended at least Sphinx version $rec_version.\n";
+ print " To upgrade, use:\n\n";
+ $rec_sphinx_upgrade = 1;
+ }
}
#
@@ -540,7 +606,7 @@ sub check_needs()
printf "\tsudo ln -sf %s /usr/bin/sphinx-build\n\n",
which("sphinx-build-3");
}
- if ($need_sphinx) {
+ if ($need_sphinx || $rec_sphinx_upgrade) {
my $activate = "$virtenv_dir/bin/activate";
if (-e "$ENV{'PWD'}/$activate") {
printf "\nNeed to activate virtualenv with:\n";
@@ -554,7 +620,8 @@ sub check_needs()
printf "\t$virtualenv $virtenv_dir\n";
printf "\t. $activate\n";
printf "\tpip install -r $requirement_file\n";
- $need++;
+
+ $need++ if (!$rec_sphinx_upgrade);
}
}
printf "\n";
--
2.21.0
^ permalink raw reply related
* [PATCH 5/8] docs: fix multiple doc build warnings in enumeration.rst
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet, Changbin Du
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
The conversion of acpi/enumeration.txt to RST included one markup error,
leading to many warnings like:
.../firmware-guide/acpi/enumeration.rst:430: WARNING: Unexpected indentation.
Add the missing colon and create some peace.
Fixes: c24bc66e8157 ("Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and convert to reST")
Cc: Changbin Du <changbin.du@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/firmware-guide/acpi/enumeration.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index 6b32b7be8c85..850be9696931 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -423,7 +423,7 @@ will be enumerated to depends on the device ID returned by _HID.
For example, the following ACPI sample might be used to enumerate an lm75-type
I2C temperature sensor and match it to the driver using the Device Tree
-namespace link:
+namespace link::
Device (TMP0)
{
--
2.21.0
^ permalink raw reply related
* [PATCH 4/8] lib/list_sort: fix kerneldoc build error
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet, George Spelvin
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Commit 043b3f7b6388 ("lib/list_sort: simplify and remove
MAX_LIST_LENGTH_BITS") added some useful kerneldoc info, but also broke the
docs build:
./lib/list_sort.c:128: WARNING: Definition list ends without a blank line; unexpected unindent.
./lib/list_sort.c:161: WARNING: Unexpected indentation.
./lib/list_sort.c:162: WARNING: Block quote ends without a blank line; unexpected unindent.
Fix the offending literal block and make the error go away.
Fixes: 043b3f7b6388 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
Cc: George Spelvin <lkml@sdf.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
lib/list_sort.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/list_sort.c b/lib/list_sort.c
index 06e900c5587b..712ed1f4eb64 100644
--- a/lib/list_sort.c
+++ b/lib/list_sort.c
@@ -120,7 +120,8 @@ static void merge_final(void *priv, cmp_func cmp, struct list_head *head,
* The latter offers a chance to save a few cycles in the comparison
* (which is used by e.g. plug_ctx_cmp() in block/blk-mq.c).
*
- * A good way to write a multi-word comparison is
+ * A good way to write a multi-word comparison is::
+ *
* if (a->high != b->high)
* return a->high > b->high;
* if (a->middle != b->middle)
--
2.21.0
^ permalink raw reply related
* [PATCH 6/8] docs/gpu: fix a documentation build break in i915.rst
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Documentation/gpu/i915.rst is not included in the TOC tree, but newer
versions of sphinx parse it anyway. That leads to this hard build failure:
> Global GTT Fence Handling
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> reST markup error:
> /stuff/k/git/kernel/Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent:
Make the underlining consistent and restore a working docs build.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 055df45596c1..cf9ff64753cc 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -401,13 +401,13 @@ GTT Fences and Swizzling
:internal:
Global GTT Fence Handling
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:doc: fence register handling
Hardware Tiling and Swizzling Details
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:doc: tiling swizzling details
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox