Великденски бонуси
Здравейте, съвременното доплащане на храна под формата на ваучери за храна, които могат да бъдат използвани в най-голямата мрежа от заведения за хранене в страната, е инструмент, който ефективно повишава ефективността на персонала. Изборът на нашите ваучери за храна като форма на социална придобивка са за работодателя не само придобиване на продуктивен и мотивиран екип, но и носят финансови облаги - стойността на изразходваните средства не се облагат с данък. Радваме се да Ви представим още повече предимства, които бихте получили с ползването на нашите ваучери, като например ползите за служителите Ви и ще Ви разкажа за възможностите при тяхното използване - моля, обадете се. Радослав Добрев Head of HR Benefit Team www.eatforyou.eu
Re: [PATCH 10/10] docs: fix broken documentation links
On Mon, May 20, 2019 at 4:48 PM Mauro Carvalho Chehab wrote: > > Mostly due to x86 and acpi conversion, several documentation > links are still pointing to the old file. Fix them. > > Signed-off-by: Mauro Carvalho Chehab For the ACPI part: Acked-by: Rafael J. Wysocki
Придобивки за персонала
Здравейте, Запознати ли сте с най-новата социална придобивка – ваучери за храна? А обмисляли ли сте използването на такива ваучери, с помощта на които Вашият персонал може да пазарува в различни вериги хранителни магазини и заведения? Бих могъл да Ви се обадя по телефона и да Ви представя възможностите на тези ваучери – моля посочете кога ще Ви бъде удобно да разговаряме. Приятен ден! Радослав Добрев Head of HR Benefit Team www.lunch4employee.eu
Re: [PATCH v2 1/3] KVM: x86: add support for user wait instructions
On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote: > This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions > in kvm, and by default dont't expose it to kvm and provide a capability > to enable it. I'm thinking this should be conditional on the guest being a 1:1 guest, and I also seem to remember we have bits for that already -- they were used to disable paravirt spinlocks for example.
[PATCH 3/3] mm: remove tmem specifics from frontswap
The frontswap module contains several parts which are specific to
tmem. With that no longer present those parts can be removed.
Signed-off-by: Juergen Gross
---
Documentation/vm/frontswap.rst | 17 +
include/linux/frontswap.h | 5 --
mm/Kconfig | 16 ++---
mm/frontswap.c | 156 +
4 files changed, 7 insertions(+), 187 deletions(-)
diff --git a/Documentation/vm/frontswap.rst b/Documentation/vm/frontswap.rst
index 511c921bc8d2..2c674c0c6a77 100644
--- a/Documentation/vm/frontswap.rst
+++ b/Documentation/vm/frontswap.rst
@@ -19,7 +19,7 @@ for a detailed overview of frontswap and related kernel parts)
Frontswap is so named because it can be thought of as the opposite of
a "backing" store for a swap device. The storage is assumed to be
a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
-to the requirements of transcendent memory (such as Xen's "tmem", or
+to the requirements of transcendent memory (such as
in-kernel compressed memory, aka "zcache", or future RAM-like devices);
this pseudo-RAM device is not directly accessible or addressable by the
kernel and is of unknown and possibly time-varying size. The driver
@@ -113,21 +113,6 @@ many servers in a cluster can swap, dynamically as needed,
to a single
server configured with a large amount of RAM... without pre-configuring
how much of the RAM is available for each of the clients!
-In the virtual case, the whole point of virtualization is to statistically
-multiplex physical resources across the varying demands of multiple
-virtual machines. This is really hard to do with RAM and efforts to do
-it well with no kernel changes have essentially failed (except in some
-well-publicized special-case workloads).
-Specifically, the Xen Transcendent Memory backend allows otherwise
-"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
-virtual machines, but the pages can be compressed and deduplicated to
-optimize RAM utilization. And when guest OS's are induced to surrender
-underutilized RAM (e.g. with "selfballooning"), sudden unexpected
-memory pressure may result in swapping; frontswap allows those pages
-to be swapped to and from hypervisor RAM (if overall host system memory
-conditions allow), thus mitigating the potentially awful performance impact
-of unplanned swapping.
-
A KVM implementation is underway and has been RFC'ed to lkml. And,
using frontswap, investigation is also underway on the use of NVM as
a memory extension technology.
diff --git a/include/linux/frontswap.h b/include/linux/frontswap.h
index 6d775984905b..052480aa3756 100644
--- a/include/linux/frontswap.h
+++ b/include/linux/frontswap.h
@@ -24,11 +24,6 @@ struct frontswap_ops {
};
extern void frontswap_register_ops(struct frontswap_ops *ops);
-extern void frontswap_shrink(unsigned long);
-extern unsigned long frontswap_curr_pages(void);
-extern void frontswap_writethrough(bool);
-#define FRONTSWAP_HAS_EXCLUSIVE_GETS
-extern void frontswap_tmem_exclusive_gets(bool);
extern bool __frontswap_test(struct swap_info_struct *, pgoff_t);
extern void __frontswap_init(unsigned type, unsigned long *map);
diff --git a/mm/Kconfig b/mm/Kconfig
index 5166fe4af00b..971b615ad3a6 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -436,20 +436,14 @@ config NEED_PER_CPU_KM
default y
config FRONTSWAP
- bool "Enable frontswap to cache swap pages if tmem is present"
+ bool "Enable frontswap to cache swap pages if zswap is present"
depends on SWAP
help
Frontswap is so named because it can be thought of as the opposite
- of a "backing" store for a swap device. The data is stored into
- "transcendent memory", memory that is not directly accessible or
- addressable by the kernel and is of unknown and possibly
- time-varying size. When space in transcendent memory is available,
- a significant swap I/O reduction may be achieved. When none is
- available, all frontswap calls are reduced to a single pointer-
- compare-against-NULL resulting in a negligible performance hit
- and swap data is stored as normal on the matching swap device.
-
- If unsure, say Y to enable frontswap.
+ of a "backing" store for a swap device. The only user right now is
+ zswap.
+
+ If unsure, say "n".
config CMA
bool "Contiguous Memory Allocator"
diff --git a/mm/frontswap.c b/mm/frontswap.c
index 157e5bf63504..e3370e46a0a5 100644
--- a/mm/frontswap.c
+++ b/mm/frontswap.c
@@ -33,23 +33,6 @@ static struct frontswap_ops *frontswap_ops __read_mostly;
#define for_each_frontswap_ops(ops)\
for ((ops) = frontswap_ops; (ops); (ops) = (ops)->next)
-/*
- * If enabled, frontswap_store will return failure even on success. As
- * a result, the swap subsystem will always write the page to swap, in
- * effect converting front
[PATCH 2/3] mm: remove cleancache.c
With the removal of tmem and xen-selfballoon the only user of cleancache is gone. Remove it, too. Signed-off-by: Juergen Gross --- Documentation/vm/cleancache.rst | 296 Documentation/vm/frontswap.rst | 10 +- Documentation/vm/index.rst | 1 - MAINTAINERS | 7 - drivers/staging/erofs/data.c | 6 - drivers/staging/erofs/internal.h | 1 - fs/block_dev.c | 5 - fs/btrfs/extent_io.c | 9 -- fs/btrfs/super.c | 2 - fs/ext4/readpage.c | 6 - fs/ext4/super.c | 2 - fs/f2fs/data.c | 3 +- fs/mpage.c | 7 - fs/ocfs2/super.c | 2 - fs/super.c | 3 - include/linux/cleancache.h | 124 --- include/linux/fs.h | 5 - mm/Kconfig | 22 --- mm/Makefile | 1 - mm/cleancache.c | 317 --- mm/filemap.c | 11 -- mm/truncate.c| 15 +- 22 files changed, 10 insertions(+), 845 deletions(-) delete mode 100644 Documentation/vm/cleancache.rst delete mode 100644 include/linux/cleancache.h delete mode 100644 mm/cleancache.c diff --git a/Documentation/vm/cleancache.rst b/Documentation/vm/cleancache.rst deleted file mode 100644 index 68cba9131c31.. --- a/Documentation/vm/cleancache.rst +++ /dev/null @@ -1,296 +0,0 @@ -.. _cleancache: - -== -Cleancache -== - -Motivation -== - -Cleancache is a new optional feature provided by the VFS layer that -potentially dramatically increases page cache effectiveness for -many workloads in many environments at a negligible cost. - -Cleancache can be thought of as a page-granularity victim cache for clean -pages that the kernel's pageframe replacement algorithm (PFRA) would like -to keep around, but can't since there isn't enough memory. So when the -PFRA "evicts" a page, it first attempts to use cleancache code to -put the data contained in that page into "transcendent memory", memory -that is not directly accessible or addressable by the kernel and is -of unknown and possibly time-varying size. - -Later, when a cleancache-enabled filesystem wishes to access a page -in a file on disk, it first checks cleancache to see if it already -contains it; if it does, the page of data is copied into the kernel -and a disk access is avoided. - -Transcendent memory "drivers" for cleancache are currently implemented -in Xen (using hypervisor memory) and zcache (using in-kernel compressed -memory) and other implementations are in development. - -:ref:`FAQs ` are included below. - -Implementation Overview -=== - -A cleancache "backend" that provides transcendent memory registers itself -to the kernel's cleancache "frontend" by calling cleancache_register_ops, -passing a pointer to a cleancache_ops structure with funcs set appropriately. -The functions provided must conform to certain semantics as follows: - -Most important, cleancache is "ephemeral". Pages which are copied into -cleancache have an indefinite lifetime which is completely unknowable -by the kernel and so may or may not still be in cleancache at any later time. -Thus, as its name implies, cleancache is not suitable for dirty pages. -Cleancache has complete discretion over what pages to preserve and what -pages to discard and when. - -Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a -pool id which, if positive, must be saved in the filesystem's superblock; -a negative return value indicates failure. A "put_page" will copy a -(presumably about-to-be-evicted) page into cleancache and associate it with -the pool id, a file key, and a page index into the file. (The combination -of a pool id, a file key, and an index is sometimes called a "handle".) -A "get_page" will copy the page, if found, from cleancache into kernel memory. -An "invalidate_page" will ensure the page no longer is present in cleancache; -an "invalidate_inode" will invalidate all pages associated with the specified -file; and, when a filesystem is unmounted, an "invalidate_fs" will invalidate -all pages in all files specified by the given pool id and also surrender -the pool id. - -An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache -to treat the pool as shared using a 128-bit UUID as a key. On systems -that may run multiple kernels (such as hard partitioned or virtualized -systems) that may share a clustered filesystem, and where cleancache -may be shared among those kernels, calls to init_shared_fs that specify the -same UUID will receive the same pool id, thus allowing the pages to -be shared. Note that any security requirements must be imposed outside -of the kernel (e.g. by "tools" that control cleancache). Or a -cleancache implementation can simply disa
[PATCH 1/3] xen: remove tmem driver
The Xen tmem (transcendent memory) driver can be removed, as the
related Xen hypervisor feature never made it past the "experimental"
state and will be removed in future Xen versions (>= 4.13).
The xen-selfballoon driver depends on tmem, so it can be removed, too.
Signed-off-by: Juergen Gross
---
Documentation/admin-guide/kernel-parameters.txt | 21 -
drivers/xen/Kconfig | 23 -
drivers/xen/Makefile| 2 -
drivers/xen/tmem.c | 419 -
drivers/xen/xen-balloon.c | 2 -
drivers/xen/xen-selfballoon.c | 579
include/xen/balloon.h | 8 -
include/xen/tmem.h | 18 -
8 files changed, 1072 deletions(-)
delete mode 100644 drivers/xen/tmem.c
delete mode 100644 drivers/xen/xen-selfballoon.c
delete mode 100644 include/xen/tmem.h
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 138f6664b2e2..2660f1a983a3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4663,27 +4663,6 @@
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
- tmem[KNL,XEN]
- Enable the Transcendent memory driver if built-in.
-
- tmem.cleancache=0|1 [KNL, XEN]
- Default is on (1). Disable the usage of the cleancache
- API to send anonymous pages to the hypervisor.
-
- tmem.frontswap=0|1 [KNL, XEN]
- Default is on (1). Disable the usage of the frontswap
- API to send swap pages to the hypervisor. If disabled
- the selfballooning and selfshrinking are force disabled.
-
- tmem.selfballooning=0|1 [KNL, XEN]
- Default is on (1). Disable the driving of swap pages
- to the hypervisor.
-
- tmem.selfshrinking=0|1 [KNL, XEN]
- Default is on (1). Partial swapoff that immediately
- transfers pages from Xen hypervisor back to the
- kernel based on different criteria.
-
topology= [S390]
Format: {off | on}
Specify if the kernel should make use of the cpu
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index ec6558b79e9d..79cc75096f42 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -10,21 +10,6 @@ config XEN_BALLOON
the system to expand the domain's memory allocation, or alternatively
return unneeded memory to the system.
-config XEN_SELFBALLOONING
- bool "Dynamically self-balloon kernel memory to target"
- depends on XEN && XEN_BALLOON && CLEANCACHE && SWAP && XEN_TMEM
- help
- Self-ballooning dynamically balloons available kernel memory driven
- by the current usage of anonymous memory ("committed AS") and
- controlled by various sysfs-settable parameters. Configuring
- FRONTSWAP is highly recommended; if it is not configured, self-
- ballooning is disabled by default. If FRONTSWAP is configured,
- frontswap-selfshrinking is enabled by default but can be disabled
- with the 'tmem.selfshrink=0' kernel boot parameter; and
self-ballooning
- is enabled by default but can be disabled with the
'tmem.selfballooning=0'
- kernel boot parameter. Note that systems without a sufficiently
- large swap device should not enable self-ballooning.
-
config XEN_BALLOON_MEMORY_HOTPLUG
bool "Memory hotplug support for Xen balloon driver"
depends on XEN_BALLOON && MEMORY_HOTPLUG
@@ -191,14 +176,6 @@ config SWIOTLB_XEN
def_bool y
select SWIOTLB
-config XEN_TMEM
- tristate
- depends on !ARM && !ARM64
- default m if (CLEANCACHE || FRONTSWAP)
- help
- Shim to interface in-kernel Transcendent Memory hooks
- (e.g. cleancache and frontswap) to Xen tmem hypercalls.
-
config XEN_PCIDEV_BACKEND
tristate "Xen PCI-device backend driver"
depends on PCI && X86 && XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index ad3844d9f876..0c4efa6fe450 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -17,14 +17,12 @@ dom0-$(CONFIG_X86) += pcpu.o
obj-$(CONFIG_XEN_DOM0) += $(dom0-y)
obj-$(CONFIG_BLOCK)+= biomerge.o
obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o
-obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o
obj-$(CONFIG_XEN_DEV_EVTCHN) += xen-evtchn.o
obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o
obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o
obj-$(CONFIG_XENFS)
[PATCH 0/3] remove tmem and code depending on it
Tmem has been an experimental Xen feature which has been dropped recently due to security problems and lack of maintainership. So it is time now to drop it in Linux kernel, too. Juergen Gross (3): xen: remove tmem driver mm: remove cleancache.c mm: remove tmem specifics from frontswap Documentation/admin-guide/kernel-parameters.txt | 21 - Documentation/vm/cleancache.rst | 296 Documentation/vm/frontswap.rst | 27 +- Documentation/vm/index.rst | 1 - MAINTAINERS | 7 - drivers/staging/erofs/data.c| 6 - drivers/staging/erofs/internal.h| 1 - drivers/xen/Kconfig | 23 - drivers/xen/Makefile| 2 - drivers/xen/tmem.c | 419 - drivers/xen/xen-balloon.c | 2 - drivers/xen/xen-selfballoon.c | 579 fs/block_dev.c | 5 - fs/btrfs/extent_io.c| 9 - fs/btrfs/super.c| 2 - fs/ext4/readpage.c | 6 - fs/ext4/super.c | 2 - fs/f2fs/data.c | 3 +- fs/mpage.c | 7 - fs/ocfs2/super.c| 2 - fs/super.c | 3 - include/linux/cleancache.h | 124 - include/linux/frontswap.h | 5 - include/linux/fs.h | 5 - include/xen/balloon.h | 8 - include/xen/tmem.h | 18 - mm/Kconfig | 38 +- mm/Makefile | 1 - mm/cleancache.c | 317 - mm/filemap.c| 11 - mm/frontswap.c | 156 +-- mm/truncate.c | 15 +- 32 files changed, 17 insertions(+), 2104 deletions(-) delete mode 100644 Documentation/vm/cleancache.rst delete mode 100644 drivers/xen/tmem.c delete mode 100644 drivers/xen/xen-selfballoon.c delete mode 100644 include/linux/cleancache.h delete mode 100644 include/xen/tmem.h delete mode 100644 mm/cleancache.c -- 2.16.4
[PATCH 1/5] scripts/sphinx-pre-install: make activate hint smarter
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
---
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
+# Copyright (c) 2017-2019 Mauro Carvalho Chehab
#
# 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
[PATCH 5/5] docs: requirements.txt: recommend Sphinx 1.7.9
As discussed at the linux-doc ML, while we'll still support version 1.3, it is time to recommend a more modern version. So, let's switch the minimal requirements to Sphinx 1.7.9, as it has the "-jauto" flag, with makes a lot faster when building documentation. Signed-off-by: Mauro Carvalho Chehab --- Documentation/doc-guide/sphinx.rst| 17 - Documentation/sphinx/requirements.txt | 4 ++-- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index c039224b404e..4ba081f43e98 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -27,8 +27,7 @@ Sphinx Install == The ReST markups currently used by the Documentation/ files are meant to be -built with ``Sphinx`` version 1.3 or higher. If you desire to build -PDF output, it is recommended to use version 1.4.6 or higher. +built with ``Sphinx`` version 1.3 or higher. There's a script that checks for the Sphinx requirements. Please see :ref:`sphinx-pre-install` for further details. @@ -56,13 +55,13 @@ or ``virtualenv``, depending on how your distribution packaged Python 3. those expressions are written using LaTeX notation. It needs texlive installed with amdfonts and amsmath in order to evaluate them. -In summary, if you want to install Sphinx version 1.4.9, you should do:: +In summary, if you want to install Sphinx version 1.7.9, you should do:: - $ virtualenv sphinx_1.4 - $ . sphinx_1.4/bin/activate - (sphinx_1.4) $ pip install -r Documentation/sphinx/requirements.txt + $ virtualenv sphinx_1.7.9 + $ . sphinx_1.7.9/bin/activate + (sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt -After running ``. sphinx_1.4/bin/activate``, the prompt will change, +After running ``. sphinx_1.7.9/bin/activate``, the prompt will change, in order to indicate that you're using the new environment. If you open a new shell, you need to rerun this command to enter again at the virtual environment before building the documentation. @@ -105,8 +104,8 @@ command line options for your distro:: You should run: sudo dnf install -y texlive-luatex85 - /usr/bin/virtualenv sphinx_1.4 - . sphinx_1.4/bin/activate + /usr/bin/virtualenv sphinx_1.7.9 + . sphinx_1.7.9/bin/activate pip install -r Documentation/sphinx/requirements.txt Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468. diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt index 742be3e12619..14e29a0ae480 100644 --- a/Documentation/sphinx/requirements.txt +++ b/Documentation/sphinx/requirements.txt @@ -1,3 +1,3 @@ -docutils==0.12 -Sphinx==1.4.9 +docutils +Sphinx==1.7.9 sphinx_rtd_theme -- 2.21.0
[PATCH 3/5] scripts/sphinx-pre-install: always check if version is compatible with build
Call the script every time a make docs target is selected, on
a simplified check mode.
With this change, the script will set two vars:
$min_version - obtained from `needs_sphinx` var inside
conf.py (currently, '1.3')
$rec_version - obtained from sphinx/requirements.txt.
With those changes, a target like "make htmldocs" will do:
1) If no sphinx-build/sphinx-build3 is found, it will run
the script on normal mode as before, checking for all
system dependencies and providing install hints for the
needed programs and will abort the build;
2) If no sphinx-build/sphinx-build3 is found, but there is
a sphinx_${VER}/bin/activate file, and if
${VER} >= $min_version (string comparation), it will
run in full mode, and will recommend to activate the
virtualenv. If there are multiple virtualenvs, it
will string sort the versions, recommending the
highest version and will abort the build;
3) If Sphinx is detected but has a version lower than
$min_version, it will run in full mode - with will
recommend creating a virtual env using sphinx/requirements.txt,
and will abort the build.
4) If Sphinx is detected and version is lower than
$rec_version, it will run in full mode and will
recommend creating a virtual env using sphinx/requirements.txt.
In this case, it **won't** abort the build.
5) If Sphinx is detected and version is equal or righer than
$rec_version it will return just after detecting the
version ("quick mode"), not checking if are there any
missing dependencies.
Just like before, if one wants to install Sphinx from the
distro, it has to call the script manually and use `--no-virtualenv`
argument to get the hints for his OS:
You should run:
sudo dnf install -y python3-sphinx python3-sphinx_rtd_theme
While here, add a small help for the three optional arguments
for the script.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/Makefile | 5 +
scripts/sphinx-pre-install | 46 +-
2 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e889e7cb8511..380e24053d6f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -70,12 +70,14 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath
$(BUILDDIR)/$3/$4)
$(abspath $(BUILDDIR)/$3/$4)
htmldocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,html,$(var),,$(var)))
linkcheckdocs:
@$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,linkcheck,$(var),,$(var)))
latexdocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,latex,$(var),latex,$(var)))
ifeq ($(HAVE_PDFLATEX),0)
@@ -87,14 +89,17 @@ pdfdocs:
else # HAVE_PDFLATEX
pdfdocs: latexdocs
+ @./scripts/sphinx-pre-install --version-check
$(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX="$(PDFLATEX)"
LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;)
endif # HAVE_PDFLATEX
epubdocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,epub,$(var),epub,$(var)))
xmldocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,xml,$(var),xml,$(var)))
endif # HAVE_SPHINX
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index ded3e2ef3f8d..f001fc2fcf12 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -38,6 +38,7 @@ my $min_version;
my $pdf = 1;
my $virtualenv = 1;
+my $version_check = 0;
#
# List of required texlive packages on Fedora and OpenSuse
@@ -277,20 +278,22 @@ sub check_sphinx()
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";
+ printf "ERROR: Sphinx version is %s. It should be >= %s
(recommended >= %s)\n",
+ $cur_version, $min_version, $rec_version;;
$need_sphinx = 1;
return;
}
if ($cur_version lt $rec_version) {
+ printf "Sphinx version %s\n", $cur_version;
print "Warning: It is recommended at least Sphinx version
$rec_version.\n";
- print " To upgrade, use:\n\n";
$rec_sphinx_upgrade = 1;
+ return;
}
+
+ # On version check mode, just assume Sphinx has all mandatory deps
+ exit (0) if ($version_check);
}
#
@@ -575,14 +578,18 @@ sub check_distros()
sub check_needs()
{
- if ($system_release) {
- print "Detected OS: $system_release.\n";
- } else
[PATCH 2/5] scripts/sphinx-pre-install: get rid of RHEL7 explicity check
RHEL8 was already launched. This test won't get it, and will
do the wrong thing. Ok, we could fix it, but now we check
Sphinx version to ensure that it matches the minimal (1.3),
so there's no need for an explicit check there.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/sphinx-pre-install | 13 -
1 file changed, 13 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 11239eb29695..ded3e2ef3f8d 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -581,19 +581,6 @@ sub check_needs()
print "Unknown OS\n";
}
- # RHEL 7.x and clones have Sphinx version 1.1.x and incomplete texlive
- if (($system_release =~ /Red Hat Enterprise Linux/) ||
- ($system_release =~ /CentOS/) ||
- ($system_release =~ /Scientific Linux/) ||
- ($system_release =~ /Oracle Linux Server/)) {
- $virtualenv = 1;
- $pdf = 0;
-
- printf("NOTE: On this distro, Sphinx and TexLive shipped
versions are incompatible\n");
- printf("with doc build. So, use Sphinx via a Python virtual
environment.\n\n");
- printf("This script can't install a TexLive version that would
provide PDF.\n");
- }
-
# Check for needed programs/tools
check_sphinx();
check_perl_module("Pod::Usage", 0);
--
2.21.0
[PATCH 4/5] docs: by default, build docs a lot faster with Sphinx >= 1.7
Since Sphinx version 1.7, it is possible to use "-jauto" in
order to speedup documentation builds. On older versions,
while -j was already supported, one would need to set the
number of threads manually.
So, if SPHINXOPTS is not provided, add -jauto, in order to
speed up the build. That makes it *a lot* times faster than
without -j.
If one really wants to slow things down, it can just use:
make SPHINXOPTS=-j1 htmldocs
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 380e24053d6f..794233d05789 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -28,6 +28,8 @@ ifeq ($(HAVE_SPHINX),0)
else # HAVE_SPHINX
+SPHINXOPTS = $(shell perl -e 'open IN,"sphinx-build --version |"; while ()
{ if (m/([\d\.]+)/) { print "-jauto" if ($$1 >= "1.7") } ;} close IN')
+
# User-friendly check for pdflatex and latexmk
HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1;
else echo 0; fi)
HAVE_LATEXMK := $(shell if which latexmk >/dev/null 2>&1; then echo 1; else
echo 0; fi)
--
2.21.0
[PATCH 0/5] Improvements to the documentation build system
The first three patches here address some issues with the script which detects the requirements for running Sphinx, making it a smarter and running it all the times, in order to allow recommending version updates. The 4th patch adds "-jauto" by default, if Sphinx version supports it (e. g. version 1.7 or upper). The final patch changes the recommendation to use at least Sphinx version 1.7.9, as discussed at linux-doc ML. Mauro Carvalho Chehab (5): scripts/sphinx-pre-install: make activate hint smarter scripts/sphinx-pre-install: get rid of RHEL7 explicity check scripts/sphinx-pre-install: always check if version is compatible with build docs: by default, build docs a lot faster with Sphinx >= 1.7 docs: requirements.txt: recommend Sphinx 1.7.9 Documentation/Makefile| 7 +++ Documentation/doc-guide/sphinx.rst| 17 +++--- Documentation/sphinx/requirements.txt | 4 +- scripts/sphinx-pre-install| 75 +++ 4 files changed, 58 insertions(+), 45 deletions(-) -- 2.21.0
Re: Ingenic Timer/Counter Unit (TCU) patchset v12
On Tue, May 21, 2019 at 4:51 PM Paul Cercueil wrote:
>
> Hi,
>
> Here's the V12 of my patchset to add support for the Timer/Counter Unit
> (TCU) present on the JZ47xx SoCs from Ingenic.
>
> This patchset is much shorter at only 13 patches vs. 27 patches in V11;
> the remaining patches will be sent in parallel (if applicable) or as a
> follow-up patchset once this one is merged.
>
> In V11 the clocksource maintainers weren't happy with the size of the
> ingenic-timer driver, which included clocks and irqchip setup code.
> On the other hand, devicetree maintainers wanted one single node for
> the TCU hardware since it's effectively just one hardware block.
>
> In this patchset the functionality is cut in four different drivers:
> a MFD one to provide the regmap, probe the children and which provides
> several API functions; a clocks driver; a irqchip driver; a clocksource
> driver. All these drivers work with the same regmap, have the same
> compatible strings, and will probe _with the same devicetree node_.
For the series:
Tested-by: Mathieu Malaterre
System: MIPS Creator CI20
For reference, here is my local patch:
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 1bfac58da5df..e7b7da32f278 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
/ {
@@ -80,6 +81,15 @@
interrupt-parent = <&intc>;
interrupts = <27 26 25>;
+
+ watchdog: watchdog@0 {
+ compatible = "ingenic,jz4780-watchdog";
+ reg = <0x0 0xc>;
+
+ clocks = <&tcu TCU_CLK_WDT>;
+ clock-names = "wdt";
+ };
+
};
rtc_dev: rtc@10003000 {
@@ -287,14 +297,6 @@
status = "disabled";
};
- watchdog: watchdog@10002000 {
- compatible = "ingenic,jz4780-watchdog";
- reg = <0x10002000 0x10>;
-
- clocks = <&cgu JZ4780_CLK_RTCLK>;
- clock-names = "rtc";
- };
-
nemc: nemc@1341 {
compatible = "ingenic,jz4780-nemc";
reg = <0x1341 0x1>;
> Regards,
> -Paul
>
>
Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
On Thu 23 May 2019 at 21:18, Atish Patra wrote: > Currently, the last stage boot loaders such as U-Boot can accept only > uImage which is an unnecessary additional step in automating boot > process. > > Add an image header that boot loader understands and boot Linux from > flat Image directly. > > This header is based on ARM64 boot image header and provides an > opportunity to combine both ARM64 & RISC-V image headers in future. > > Also make sure that PE/COFF header can co-exist in the same image so > that EFI stub can be supported for RISC-V in future. EFI specification > needs PE/COFF image header in the beginning of the kernel image in order > to load it as an EFI application. In order to support EFI stub, code0 > should be replaced with "MZ" magic string and res4(at offset 0x3c) > should point to the rest of the PE/COFF header (which will be added > during EFI support). > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux. Thanks Atish, happy to have this support that makes the boot process more straightforward. Tested on HiFive Unleashed using OpenSBI + U-Boot v2019.07-rc2 + Linux. > > Signed-off-by: Atish Patra > Reviewed-by: Karsten Merker > Tested-by: Karsten Merker (QEMU+OpenSBI+U-Boot) Tested-by: Loys Ollivier
Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
On Fri, 24 May 2019 at 06:18, Atish Patra wrote: > > Currently, the last stage boot loaders such as U-Boot can accept only > uImage which is an unnecessary additional step in automating boot > process. > > Add an image header that boot loader understands and boot Linux from > flat Image directly. > > This header is based on ARM64 boot image header and provides an > opportunity to combine both ARM64 & RISC-V image headers in future. > > Also make sure that PE/COFF header can co-exist in the same image so > that EFI stub can be supported for RISC-V in future. EFI specification > needs PE/COFF image header in the beginning of the kernel image in order > to load it as an EFI application. In order to support EFI stub, code0 > should be replaced with "MZ" magic string and res4(at offset 0x3c) > should point to the rest of the PE/COFF header (which will be added > during EFI support). > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux. > > Signed-off-by: Atish Patra > Reviewed-by: Karsten Merker > Tested-by: Karsten Merker (QEMU+OpenSBI+U-Boot) > > --- > I have not sent out corresponding U-Boot patch as all the changes are > compatible with current u-boot support. Once, the kernel header format > is agreed upon, I will update the U-Boot patch. > > Changes from v3->v4 > 1. Update the commit text to clarify about PE/COFF header. > > Changes from v2->v3 > 1. Modified reserved fields to define a header version. > 2. Added header documentation. > > Changes from v1-v2: > 1. Added additional reserved elements to make it fully PE compatible. > --- > Documentation/riscv/boot-image-header.txt | 50 ++ > arch/riscv/include/asm/image.h| 64 +++ > arch/riscv/kernel/head.S | 32 > 3 files changed, 146 insertions(+) > create mode 100644 Documentation/riscv/boot-image-header.txt > create mode 100644 arch/riscv/include/asm/image.h > > diff --git a/Documentation/riscv/boot-image-header.txt > b/Documentation/riscv/boot-image-header.txt > new file mode 100644 > index ..68abc2353cec > --- /dev/null > +++ b/Documentation/riscv/boot-image-header.txt > @@ -0,0 +1,50 @@ > + Boot image header in RISC-V Linux > + = > + > +Author: Atish Patra > +Date : 20 May 2019 > + > +This document only describes the boot image header details for RISC-V Linux. > +The complete booting guide will be available at > Documentation/riscv/booting.txt. > + > +The following 64-byte header is present in decompressed Linux kernel image. > + > + u32 code0;/* Executable code */ > + u32 code1;/* Executable code */ Apologies for not mentioning this in my previous reply, but given that you already know that you will need to put the magic string MZ at offset 0x0, it makes more sense to not put any code there at all, but educate the bootloader that the first executable instruction is at offset 0x20, and put the spare fields right after it in case you ever need more than 2 slots. (On arm64, we were lucky to be able to find an opcode that happened to contain the MZ bit pattern and act almost like a NOP, but it seems silly to rely on that for RISC-V as well) So something like u16 pe_res1; /* MZ for EFI bootable images, don't care otherwise */ u8 magic[6];/* "RISCV\0" u64 text_offset; /* Image load offset, little endian */ u64 image_size; /* Effective Image size, little endian */ u64 flags;/* kernel flags, little endian */ u32 code0;/* Executable code */ u32 code1;/* Executable code */ u64 reserved[2]; /* reserved for future use */ u32 version; /* Version of this header */ u32 pe_res2; /* Reserved for PE COFF offset */ > +This header format is compliant with PE/COFF header and largely inspired from > +ARM64 header. Thus, both ARM64 & RISC-V header can be combined into one > common > +header in future. > + > +Notes: > +- This header can also be reused to support EFI stub for RISC-V in future. > EFI > + specification needs PE/COFF image header in the beginning of the kernel > image > + in order to load it as an EFI application. In order to support EFI stub, > + code0 should be replaced with "MZ" magic string and res5(at offset 0x3c) > should > + point to the rest of the PE/COFF header. > + > +- version field indicate header version number. > + Bits 0:15 - Minor version > + Bits 16:31 - Major version > + > + This preserves compatibility across newer and older version of the header. > + The current version is defined as 0.1. > + > +- res3 is reserved for offset to any other additional fields. This makes the > + header extendible in future. One example would be to accommodate ISA > + extension for RISC-V in future. For current version, it is set to be zero. > + > +- In current heade
Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote: > On Fri, 24 May 2019 at 06:18, Atish Patra wrote: > > Currently, the last stage boot loaders such as U-Boot can accept only > > uImage which is an unnecessary additional step in automating boot > > process. > > > > Add an image header that boot loader understands and boot Linux from > > flat Image directly. > > > > This header is based on ARM64 boot image header and provides an > > opportunity to combine both ARM64 & RISC-V image headers in future. > > > > Also make sure that PE/COFF header can co-exist in the same image so > > that EFI stub can be supported for RISC-V in future. EFI specification > > needs PE/COFF image header in the beginning of the kernel image in order > > to load it as an EFI application. In order to support EFI stub, code0 > > should be replaced with "MZ" magic string and res4(at offset 0x3c) > > should point to the rest of the PE/COFF header (which will be added > > during EFI support). [...] > > Documentation/riscv/boot-image-header.txt | 50 ++ > > arch/riscv/include/asm/image.h| 64 +++ > > arch/riscv/kernel/head.S | 32 > > 3 files changed, 146 insertions(+) > > create mode 100644 Documentation/riscv/boot-image-header.txt > > create mode 100644 arch/riscv/include/asm/image.h > > > > diff --git a/Documentation/riscv/boot-image-header.txt > > b/Documentation/riscv/boot-image-header.txt > > new file mode 100644 > > index ..68abc2353cec > > --- /dev/null > > +++ b/Documentation/riscv/boot-image-header.txt > > @@ -0,0 +1,50 @@ > > + Boot image header in RISC-V Linux > > + = > > + > > +Author: Atish Patra > > +Date : 20 May 2019 > > + > > +This document only describes the boot image header details for RISC-V > > Linux. > > +The complete booting guide will be available at > > Documentation/riscv/booting.txt. > > + > > +The following 64-byte header is present in decompressed Linux kernel image. > > + > > + u32 code0;/* Executable code */ > > + u32 code1;/* Executable code */ > > Apologies for not mentioning this in my previous reply, but given that > you already know that you will need to put the magic string MZ at > offset 0x0, it makes more sense to not put any code there at all, but > educate the bootloader that the first executable instruction is at > offset 0x20, and put the spare fields right after it in case you ever > need more than 2 slots. (On arm64, we were lucky to be able to find an > opcode that happened to contain the MZ bit pattern and act almost like > a NOP, but it seems silly to rely on that for RISC-V as well) > > So something like > > u16 pe_res1; /* MZ for EFI bootable images, don't care otherwise */ > u8 magic[6];/* "RISCV\0" > > u64 text_offset; /* Image load offset, little endian */ > u64 image_size; /* Effective Image size, little endian */ > u64 flags;/* kernel flags, little endian */ > > u32 code0;/* Executable code */ > u32 code1;/* Executable code */ > > u64 reserved[2]; /* reserved for future use */ > > u32 version; /* Version of this header */ > u32 pe_res2; /* Reserved for PE COFF offset */ Hello, wouldn't that immediately break existing systems (including qemu when loading kernels with the "-kernel" option) that rely on the fact that the kernel entry point is always at the kernel load address? The ARM64 header and Atish's original RISC-V proposal based on the ARM64 header keep the property that jumping to the kernel load address always works, regardless of what the particular header looks like and which potential future extensions it includes, but the proposed change above wouldn't do that. Although I agree that having to integrate the "MZ" string as an instruction isn't particularly nice, I don't think that this is a sufficient justification for breaking compatibility with prior kernel releases and/or existing boot firmware. On RISC-V, the "MZ" string is a compressed load immediate to x20/s4, i.e. an instruction that should be "harmless" as far as the kernel boot flow is concerned as the x20/s4 register AFAIK doesn't contain any information that the kernel would use. Regards, Karsten -- Ich widerspreche hiermit ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
[PATCH 5/7] docs: no structured comments in fs/file_table.c
Remove the kernel-doc directive, since there are only warnings to be found there. Signed-off-by: Jonathan Corbet --- Documentation/filesystems/api-summary.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/Documentation/filesystems/api-summary.rst b/Documentation/filesystems/api-summary.rst index aa51ffcfa029..bbb0c1c0e5cf 100644 --- a/Documentation/filesystems/api-summary.rst +++ b/Documentation/filesystems/api-summary.rst @@ -89,9 +89,6 @@ Other Functions .. kernel-doc:: fs/direct-io.c :export: -.. kernel-doc:: fs/file_table.c - :export: - .. kernel-doc:: fs/libfs.c :export: -- 2.21.0
[PATCH 1/7] docs: Do not seek comments in kernel/rcu/tree_plugin.h
There are no kerneldoc comments in this file, so do not attempt to include them in the docs build. Signed-off-by: Jonathan Corbet --- Documentation/core-api/kernel-api.rst | 2 -- Documentation/driver-api/basics.rst | 3 --- 2 files changed, 5 deletions(-) diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index a29c99d13331..a53ec2eb8176 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -358,8 +358,6 @@ Read-Copy Update (RCU) .. kernel-doc:: kernel/rcu/tree.c -.. kernel-doc:: kernel/rcu/tree_plugin.h - .. kernel-doc:: kernel/rcu/tree_exp.h .. kernel-doc:: kernel/rcu/update.c diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index e970fadf4d1a..1ba88c7b3984 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -115,9 +115,6 @@ Kernel utility functions .. kernel-doc:: kernel/rcu/tree.c :export: -.. kernel-doc:: kernel/rcu/tree_plugin.h - :export: - .. kernel-doc:: kernel/rcu/update.c :export: -- 2.21.0
[PATCH 4/7] docs: No structured comments in target_core_device.c
Documentation/driver-api/target.rst is seeking kerneldoc comments in drivers/target/target_core_device.c, but no such comments exist. Take out the kernel-doc directive and eliminate one warning from the build. Signed-off-by: Jonathan Corbet --- Documentation/driver-api/target.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/driver-api/target.rst b/Documentation/driver-api/target.rst index 4363611dd86d..620ec6173a93 100644 --- a/Documentation/driver-api/target.rst +++ b/Documentation/driver-api/target.rst @@ -10,8 +10,8 @@ TBD Target core device interfaces = -.. kernel-doc:: drivers/target/target_core_device.c -:export: +This section is blank because no kerneldoc comments have been added to +drivers/target/target_core_device.c. Target core transport interfaces -- 2.21.0
[PATCH 0/7] The eternal battle against docs-build warnings
Here's a collection of trivial changes meant to eliminate a number of "no structured comments found" warnings - plus a kernel-doc tweak to make those problems easier to track down. Jonathan Corbet (7): docs: Do not seek comments in kernel/rcu/tree_plugin.h docs: Fix a misdirected kerneldoc directive docs: Do not seek kerneldoc comments in hw-consumer.h docs: No structured comments in target_core_device.c docs: no structured comments in fs/file_table.c docs: No structured comments in include/linux/interconnect.h kernel-doc: always name missing kerneldoc sections Documentation/core-api/kernel-api.rst| 2 -- Documentation/driver-api/basics.rst | 3 --- .../driver-api/firmware/other_interfaces.rst | 2 +- Documentation/driver-api/iio/hw-consumer.rst | 1 - Documentation/driver-api/target.rst | 4 ++-- Documentation/filesystems/api-summary.rst| 3 --- Documentation/interconnect/interconnect.rst | 5 ++--- scripts/kernel-doc | 16 +--- 8 files changed, 14 insertions(+), 22 deletions(-) -- 2.21.0
[PATCH 7/7] kernel-doc: always name missing kerneldoc sections
The "no structured comments found" warning is not particularly useful if
there are several invocations, one of which is looking for something
wrong. So if something specific has been requested, make it clear that
it's the one we weren't able to find.
Signed-off-by: Jonathan Corbet
---
scripts/kernel-doc | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 3350e498b4ce..c0cb41e65b9b 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -285,7 +285,7 @@ use constant {
OUTPUT_INTERNAL => 4, # output non-exported symbols
};
my $output_selection = OUTPUT_ALL;
-my $show_not_found = 0;
+my $show_not_found = 0;# No longer used
my @export_file_list;
@@ -435,7 +435,7 @@ while ($ARGV[0] =~ m/^--?(.*)/) {
} elsif ($cmd eq 'enable-lineno') {
$enable_lineno = 1;
} elsif ($cmd eq 'show-not-found') {
- $show_not_found = 1;
+ $show_not_found = 1; # A no-op but don't fail
} else {
# Unknown argument
usage();
@@ -2163,12 +2163,14 @@ sub process_file($) {
}
# Make sure we got something interesting.
-if ($initial_section_counter == $section_counter) {
- if ($output_mode ne "none") {
- print STDERR "${file}:1: warning: no structured comments found\n";
+if ($initial_section_counter == $section_counter && $
+ output_mode ne "none") {
+ if ($output_selection == OUTPUT_INCLUDE) {
+ print STDERR "${file}:1: warning: '$_' not found\n"
+ for keys %function_table;
}
- if (($output_selection == OUTPUT_INCLUDE) && ($show_not_found == 1)) {
- print STDERR "Was looking for '$_'.\n" for keys %function_table;
+ else {
+ print STDERR "${file}:1: warning: no structured comments found\n";
}
}
}
--
2.21.0
[PATCH 6/7] docs: No structured comments in include/linux/interconnect.h
Remove the kernel-doc directive for this file, since there's nothing there and it generates a warning. Signed-off-by: Jonathan Corbet --- Documentation/interconnect/interconnect.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst index b8107dcc4cd3..c3e004893796 100644 --- a/Documentation/interconnect/interconnect.rst +++ b/Documentation/interconnect/interconnect.rst @@ -89,6 +89,5 @@ Interconnect consumers Interconnect consumers are the clients which use the interconnect APIs to get paths between endpoints and set their bandwidth/latency/QoS requirements -for these interconnect paths. - -.. kernel-doc:: include/linux/interconnect.h +for these interconnect paths. These interfaces are not currently +documented. -- 2.21.0
[PATCH 2/7] docs: Fix a misdirected kerneldoc directive
The stratix10 service layer documentation tried to include a kerneldoc comments for a nonexistent struct; leading to a "no structured comments found" message. Switch it to stratix10_svc_command_config_type, which appears at that spot in the sequence and was not included. Signed-off-by: Jonathan Corbet --- Documentation/driver-api/firmware/other_interfaces.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst index a4ac54b5fd79..b81794e0cfbb 100644 --- a/Documentation/driver-api/firmware/other_interfaces.rst +++ b/Documentation/driver-api/firmware/other_interfaces.rst @@ -33,7 +33,7 @@ of the requests on to a secure monitor (EL3). :functions: stratix10_svc_client_msg .. kernel-doc:: include/linux/firmware/intel/stratix10-svc-client.h - :functions: stratix10_svc_command_reconfig_payload + :functions: stratix10_svc_command_config_type .. kernel-doc:: include/linux/firmware/intel/stratix10-svc-client.h :functions: stratix10_svc_cb_data -- 2.21.0
[PATCH 3/7] docs: Do not seek kerneldoc comments in hw-consumer.h
There are no kerneldoc comments here, so looking for them just yields a warning in the docs build. Signed-off-by: Jonathan Corbet --- Documentation/driver-api/iio/hw-consumer.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst index e0fe0b98230e..819fb9edc005 100644 --- a/Documentation/driver-api/iio/hw-consumer.rst +++ b/Documentation/driver-api/iio/hw-consumer.rst @@ -45,7 +45,6 @@ A typical IIO HW consumer setup looks like this:: More details -.. kernel-doc:: include/linux/iio/hw-consumer.h .. kernel-doc:: drivers/iio/buffer/industrialio-hw-consumer.c :export: -- 2.21.0
Re: [PATCH v2 1/3] KVM: x86: add support for user wait instructions
On 27/05/2019 18:30, Peter Zijlstra wrote: On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote: This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions in kvm, and by default dont't expose it to kvm and provide a capability to enable it. I'm thinking this should be conditional on the guest being a 1:1 guest, and I also seem to remember we have bits for that already -- they were used to disable paravirt spinlocks for example. Hi Peter, I am wondering if "1:1 guest" means different guests in the same host should have different settings on user wait instructions? User wait instructions(UMONITOR, UMWAIT and TPAUSE) can use in guest only when the VMCS Secondary Processor-Based VM-Execution Control bit 26 is 1, otherwise any execution of TPAUSE, UMONITOR, or UMWAIT causes a #UD. So with a capability to enable it, we use qemu kvm_vm_ioctl_enable_cap() to enable it. The qemu link is blew: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05810.html By using different QEMU parameters, different guests in the same host would have different features with or without user wait instructions. About "disable paravirt spinlocks" case, I am wondering if it uses kernel parameters? If it uses kernel parameters, different guests in the same host may have same settings on user wait instructions. Or when we uses kernel parameters to disable user wait instructions, for a host chooses to enable user wait instructions, we should do some work on QEMU to choose disable or enable user wait instructions? Thanks Tao
Re: [PATCH v2 1/3] KVM: x86: add support for user wait instructions
On Tue, 28 May 2019 at 13:16, Tao Xu wrote: > > > On 27/05/2019 18:30, Peter Zijlstra wrote: > > On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote: > >> This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions > >> in kvm, and by default dont't expose it to kvm and provide a capability > >> to enable it. > > > > I'm thinking this should be conditional on the guest being a 1:1 guest, > > and I also seem to remember we have bits for that already -- they were > > used to disable paravirt spinlocks for example. > > > > Hi Peter, > > I am wondering if "1:1 guest" means different guests in the same host > should have different settings on user wait instructions? > > User wait instructions(UMONITOR, UMWAIT and TPAUSE) can use in guest > only when the VMCS Secondary Processor-Based VM-Execution Control bit 26 > is 1, otherwise any execution of TPAUSE, UMONITOR, or UMWAIT causes a #UD. > > So with a capability to enable it, we use qemu kvm_vm_ioctl_enable_cap() > to enable it. The qemu link is blew: > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05810.html > > By using different QEMU parameters, different guests in the same host > would have different features with or without user wait instructions. > > About "disable paravirt spinlocks" case, I am wondering if it uses Please refer to a4429e53c9 (KVM: Introduce paravirtualization hints and KVM_HINTS_DEDICATED) and b2798ba0b87 (KVM: X86: Choose qspinlock when dedicated physical CPUs are available). > kernel parameters? If it uses kernel parameters, different guests in the > same host may have same settings on user wait instructions. > > Or when we uses kernel parameters to disable user wait instructions, for > a host chooses to enable user wait instructions, we should do some work > on QEMU to choose disable or enable user wait instructions? > > Thanks > > Tao
