* Re: [PATCH v3] Add a document on rebasing and merging
From: Dmitry Vyukov @ 2019-06-14 9:59 UTC (permalink / raw)
To: Jonathan Corbet
Cc: open list:DOCUMENTATION, LKML, Theodore Ts'o,
Geert Uytterhoeven, David Rientjes, Jani Nikula, Michael Ellerman
In-Reply-To: <20190612094503.120f699a@lwn.net>
On Wed, Jun 12, 2019 at 5:45 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
> Every merge window seems to involve at least one episode where subsystem
> maintainers don't manage their trees as Linus would like. Document the
> expectations so that at least he has something to point people to.
>
> Acked-by: David Rientjes <rientjes@google.com>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> ---
> I intend to apply this version unless somebody really screams.
>
> Changes in v3
> - Fill out discussion on back merges and topic branches as suggested by
> Jani.
>
> Changes in v2:
> - Try to clear up "reparenting" v. "history modification"
> - Make the "don't rebase public branches" rule into more of a guideline
> - Fix typos noted by Geert
> - Rename the document to better reflect its contents
>
> Documentation/maintainer/index.rst | 1 +
> .../maintainer/rebasing-and-merging.rst | 226 ++++++++++++++++++
> 2 files changed, 227 insertions(+)
> create mode 100644 Documentation/maintainer/rebasing-and-merging.rst
>
> diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
> index 2a14916930cb..56e2c09dfa39 100644
> --- a/Documentation/maintainer/index.rst
> +++ b/Documentation/maintainer/index.rst
> @@ -10,5 +10,6 @@ additions to this manual.
> :maxdepth: 2
>
> configure-git
> + rebasing-and-merging
> pull-requests
>
> diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst
> new file mode 100644
> index 000000000000..5da9da7a2c51
> --- /dev/null
> +++ b/Documentation/maintainer/rebasing-and-merging.rst
> @@ -0,0 +1,226 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +====================
> +Rebasing and merging
> +====================
> +
> +Maintaining a subsystem, as a general rule, requires a familiarity with the
> +Git source-code management system. Git is a powerful tool with a lot of
> +features; as is often the case with such tools, there are right and wrong
> +ways to use those features. This document looks in particular at the use
> +of rebasing and merging. Maintainers often get in trouble when they use
> +those tools incorrectly, but avoiding problems is not actually all that
> +hard.
> +
> +One thing to be aware of in general is that, unlike many other projects,
> +the kernel community is not scared by seeing merge commits in its
> +development history. Indeed, given the scale of the project, avoiding
> +merges would be nearly impossible.
Hi Jonathan,
I will appreciate if you elaborate a bit on this "scale of the
project". I wondered about reasons for having the current hierarchy of
trees and complex merging for a while, but wasn't able to find any
rationale. What exactly scale do you mean? I know a number of projects
that are comparable to Linux kernel, with the largest being 2 orders
of magnitude larger than kernel both in terms of code size and rate of
change, that use single tree and linear history. So these scales do
not seem to inherently require multiple trees and non-linear history.
Maybe this is already documented somewhere?
Thanks
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Ilias Apalodimas @ 2019-06-14 10:34 UTC (permalink / raw)
To: Sasha Levin
Cc: Sumit Garg, peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <20190613171141.GL1513@sasha-vm>
Hi Sasha,
On Thu, Jun 13, 2019 at 01:11:41PM -0400, Sasha Levin wrote:
> On Wed, Jun 05, 2019 at 04:39:36PM +0530, Sumit Garg wrote:
> >On Wed, 5 Jun 2019 at 01:39, Sasha Levin <sashal@kernel.org> wrote:
> >>
> >>On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
> >>>On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
> >>>> + /* Open context with TEE driver */
> >>>> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
> >>>> + NULL);
> >>>> + if (IS_ERR(pvt_data->ctx)) {
> >>>> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
> >>>
> >>>Is this well tested? I see this misleading error multiple times as
> >>>follows although TEE driver works pretty well.
> >>
> >>Yes, this was all functionally tested.
I did test as well with a DeveloperBox, i can confirm the driver is loading (but
i have no fTPM support on the OP-TEE side for now)
apalos@mule:~>sudo dmesg | grep optee
[sudo] password for apalos:
[ 5.035801] optee: probing for conduit method from DT.
[ 5.041045] optee: revision 3.2 (53bf1c38)
[ 5.041772] optee: initialized driver
apalos@mule:~>sudo dmesg | grep tpm
[ 5.000674] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
[ 5.101655] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_session failed,
err=ffff000c
[ 5.109703] ftpm-tee: probe of tpm@0 failed with error -22
The error -22 is nice since the probe eventually failed (no fTPM support in
secure world). Can we slightly change the
'ftpm_tee_probe:tee_client_open_context failed' and indicate this is not a real
error since the probe gets deferred untill Secure world is alive?
By the way there is *real* interest for this functionality. I expect to run it
on a number of Arm boards once i get some free time.
> >Can you share your build instructions and testing approach?
>
> Yes: it looks like you got all the kernel bits, but not the firmware.
> There are instructions for it here: https://github.com/microsoft/ms-tpm-20-ref
>
> Once it's running, you can test it by running your favorite TPM usecases
> through /dev/tpm0.
>
> --
> Thanks,
> Sasha
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sumit Garg @ 2019-06-14 10:41 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <CAFA6WYMOjgHRw9RVrjherNo0ZNbTtEonPwSFFC0dT4CZO=A1NQ@mail.gmail.com>
On Wed, 5 Jun 2019 at 16:39, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Wed, 5 Jun 2019 at 01:39, Sasha Levin <sashal@kernel.org> wrote:
> >
> > On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
> > >On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
> > >> + /* Open context with TEE driver */
> > >> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
> > >> + NULL);
> > >> + if (IS_ERR(pvt_data->ctx)) {
> > >> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
> > >
> > >Is this well tested? I see this misleading error multiple times as
> > >follows although TEE driver works pretty well.
> >
> > Yes, this was all functionally tested.
>
> Can you share your build instructions and testing approach?
>
> >
> > Why is this error message misleading? I'd be happy to fix it.
>
But still this message should be updated to represent correct status.
Maybe something like:
dev_warn(dev, "waiting for OP-TEE to be alive\n");
> IIUC, here you are trying to resolve dependency with OP-TEE driver
> using "-EPROBE_DEFER". So user shouldn't be prompted with error
> messages until OP-TEE driver comes up.
>
> BTW, for me this OP-TEE driver dependency seems not to work, boot is
> simply stuck waiting for device. Probably the reason being this fTPM
> driver is a platform driver and OP-TEE NOT a platform driver.
>
Apologies for the noise here. It works as expected.
-Sumit
> >
> > >Module built with "CONFIG_TCG_FTPM_TEE=y"
> > >
> > >[ 1.436878] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> > >[ 1.509471] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> > >[ 1.517268] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> > >[ 1.525596] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> >
> > Does the TEE have the fTPM implementation and such? Could you provide
> > details about your testing environment (hardware, fTPM verions, etc)?
> >
>
> I just did a sanity check on my arm64 machine (Developerbox), just
> adding following DT node and enabled CONFIG_TCG_FTPM_TEE=y:
>
> + tpm@0 {
> + compatible = "microsoft,ftpm";
> + };
>
> Basically with no fTPM TA, I expected the driver to fail during
> "tee_client_open_session()" call with TA not found error and boot
> should continue. But it fails during "tee_client_open_context()" which
> opens a context with OP-TEE driver and has nothing to do with fTPM TA.
>
> -Sumit
>
> > --
> > Thanks,
> > Sasha
^ permalink raw reply
* Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
From: Guenter Roeck @ 2019-06-14 12:37 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Esben Haabendal, Jerry Hoemann, Rasmus Villemoes
In-Reply-To: <56280052-9437-9813-a24e-125abb876762@prevas.dk>
On 6/14/19 1:41 AM, Rasmus Villemoes wrote:
> On 07/06/2019 20.38, Guenter Roeck wrote:
>> On Wed, Jun 05, 2019 at 02:06:44PM +0000, Rasmus Villemoes wrote:
>>> When the watchdog device is not open by userspace, the kernel takes
>>> care of pinging it. When the open_timeout feature is in use, we should
>>> ensure that the hardware fires close to open_timeout seconds after the
>>> kernel has assumed responsibility for the device.
>>>
>>> To do this, simply reuse the logic that is already in place for
>>> ensuring the same thing when userspace is responsible for regularly
>>> pinging the device:
>>>
>>> - When watchdog_active(wdd), this patch doesn't change anything.
>>>
>>> - When !watchdoc_active(wdd), the "virtual timeout" should be taken to
>>
>> s/watchdoc_active/watchdog_active/
>>
>> otherwise
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Thanks! Wim, can you fix up if/when applying, or do you prefer I resend?
>
I made the change when applying the patch to my watchdog-next branch,
and Wim usually picks up patches from there, so we should be good.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Jani Nikula @ 2019-06-14 13:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mauro Carvalho Chehab
In-Reply-To: <196fb3c497546f923bf5d156c3fddbe74a4913bc.1560477540.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> Add a script to parse the Documentation/ABI files and produce
> an output with all entries inside an ABI (sub)directory.
>
> Right now, it outputs its contents on ReST format. It shouldn't
> be hard to make it produce other kind of outputs, since the ABI
> file parser is implemented in separate than the output generator.
Hum, or just convert the ABI files to rst directly.
BR,
Jani.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> scripts/get_abi.pl | 212 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 212 insertions(+)
> create mode 100755 scripts/get_abi.pl
>
> diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
> new file mode 100755
> index 000000000000..f7c9944a833c
> --- /dev/null
> +++ b/scripts/get_abi.pl
> @@ -0,0 +1,212 @@
> +#!/usr/bin/perl
> +
> +use strict;
> +use Pod::Usage;
> +use Getopt::Long;
> +use File::Find;
> +use Fcntl ':mode';
> +
> +my $help;
> +my $man;
> +my $debug;
> +
> +GetOptions(
> + "debug|d+" => \$debug,
> + 'help|?' => \$help,
> + man => \$man
> +) or pod2usage(2);
> +
> +pod2usage(1) if $help;
> +pod2usage(-exitstatus => 0, -verbose => 2) if $man;
> +
> +pod2usage(2) if (scalar @ARGV != 1);
> +
> +my ($prefix) = @ARGV;
> +
> +require Data::Dumper if ($debug);
> +
> +my %data;
> +
> +#
> +# Displays an error message, printing file name and line
> +#
> +sub parse_error($$$$) {
> + my ($file, $ln, $msg, $data) = @_;
> +
> + print STDERR "file $file#$ln: $msg at\n\t$data";
> +}
> +
> +#
> +# Parse an ABI file, storing its contents at %data
> +#
> +sub parse_abi {
> + my $file = $File::Find::name;
> +
> + my $mode = (stat($file))[2];
> + return if ($mode & S_IFDIR);
> + return if ($file =~ m,/README,);
> +
> + my $name = $file;
> + $name =~ s,.*/,,;
> +
> + my $type = $file;
> + $type =~ s,.*/(.*)/.*,$1,;
> +
> + my $what;
> + my $new_what;
> + my $tag;
> + my $ln;
> +
> + print STDERR "Opening $file\n" if ($debug > 1);
> + open IN, $file;
> + while(<IN>) {
> + $ln++;
> + if (m/^(\S+):\s*(.*)/i) {
> + my $new_tag = lc($1);
> + my $content = $2;
> +
> + if (!($new_tag =~ m/(what|date|kernelversion|contact|description|users)/)) {
> + if ($tag eq "description") {
> + $data{$what}->{$tag} .= "\n$content";;
> + $data{$what}->{$tag} =~ s/\n+$//;
> + next;
> + } else {
> + parse_error($file, $ln, "tag '$tag' is invalid", $_);
> + }
> + }
> +
> + if ($new_tag =~ m/what/) {
> + if ($tag =~ m/what/) {
> + $what .= ", " . $content;
> + } else {
> + $what = $content;
> + $new_what = 1;
> + }
> + $tag = $new_tag;
> + next;
> + }
> +
> + $tag = $new_tag;
> +
> + if ($new_what) {
> + $new_what = 0;
> +
> + $data{$what}->{type} = $type;
> + $data{$what}->{file} = $name;
> + print STDERR "\twhat: $what\n" if ($debug > 1);
> + }
> +
> + if (!$what) {
> + parse_error($file, $ln, "'What:' should come first:", $_);
> + next;
> + }
> + $data{$what}->{$tag} = $content;
> + next;
> + }
> +
> + # Silently ignore any headers before the database
> + next if (!$tag);
> +
> + if (m/^\s*(.*)/) {
> + $data{$what}->{$tag} .= "\n$1";
> + $data{$what}->{$tag} =~ s/\n+$//;
> + next;
> + }
> +
> + # Everything else is error
> + parse_error($file, $ln, "Unexpected line:", $_);
> + }
> + close IN;
> +}
> +
> +# Outputs the output on ReST format
> +sub output_rest {
> + foreach my $what (sort keys %data) {
> + my $type = $data{$what}->{type};
> + my $file = $data{$what}->{file};
> +
> + my $w = $what;
> + $w =~ s/([\(\)\_\-\*\=\^\~\\])/\\$1/g;
> +
> + print "$w\n\n";
> + print "- defined on file $file (type: $type)\n\n::\n\n";
> +
> + my $desc = $data{$what}->{description};
> + $desc =~ s/^\s+//;
> +
> + # Remove title markups from the description, as they won't work
> + $desc =~ s/\n[\-\*\=\^\~]+\n/\n/g;
> +
> + # put everything inside a code block
> + $desc =~ s/\n/\n /g;
> +
> +
> + if (!($desc =~ /^\s*$/)) {
> + print " $desc\n\n";
> + } else {
> + print " DESCRIPTION MISSING\n\n";
> + }
> + }
> +}
> +
> +#
> +# Parses all ABI files located at $prefix dir
> +#
> +find({wanted =>\&parse_abi, no_chdir => 1}, $prefix);
> +
> +print STDERR Data::Dumper->Dump([\%data], [qw(*data)]) if ($debug);
> +
> +#
> +# Outputs an ReST file with the ABI contents
> +#
> +output_rest
> +
> +
> +__END__
> +
> +=head1 NAME
> +
> +abi_book.pl - parse the Linux ABI files and produce a ReST book.
> +
> +=head1 SYNOPSIS
> +
> +B<abi_book.pl> [--debug] <ABI_DIR>]
> +
> +=head1 OPTIONS
> +
> +=over 8
> +
> +=item B<--debug>
> +
> +Put the script in verbose mode, useful for debugging. Can be called multiple
> +times, to increase verbosity.
> +
> +=item B<--help>
> +
> +Prints a brief help message and exits.
> +
> +=item B<--man>
> +
> +Prints the manual page and exits.
> +
> +=back
> +
> +=head1 DESCRIPTION
> +
> +Parse the Linux ABI files from ABI DIR (usually located at Documentation/ABI)
> +and produce a ReST book containing the Linux ABI.
> +
> +=head1 BUGS
> +
> +Report bugs to Mauro Carvalho Chehab <mchehab@s-opensource.com>
> +
> +=head1 COPYRIGHT
> +
> +Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab@s-opensource.com>.
> +
> +License GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>.
> +
> +This is free software: you are free to change and redistribute it.
> +There is NO WARRANTY, to the extent permitted by law.
> +
> +=cut
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Jani Nikula @ 2019-06-14 13:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mauro Carvalho Chehab
In-Reply-To: <9da2a7f6ff57d9d53dcbb964eb310f7956522870.1560477540.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> As we don't want a generic Sphinx extension to execute commands,
> change the one proposed to Markus to call the abi_book.pl
> script.
>
> Use a script to parse the Documentation/ABI directory and output
> it at the admin-guide.
We had a legacy kernel-doc perl script so we used that instead of
rewriting it in python. Just to keep it bug-for-bug compatible with the
past. That was the only reason.
I see absolutely zero reason to add a new perl monstrosity with a python
extension to call it. All of this could be better done in python,
directly.
Please don't complicate the documentation build. I know you know we all
worked hard to take apart the old DocBook Rube Goldberg machine to
replace it with Sphinx. Please don't turn the Sphinx build to another
complicated mess.
My strong preferences are, in this order:
1) Convert the ABI documentation to reStructuredText
2) Have the python extension read the ABI files directly, without an
extra pipeline.
BR,
Jani.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/admin-guide/abi-obsolete.rst | 10 ++
> Documentation/admin-guide/abi-removed.rst | 4 +
> Documentation/admin-guide/abi-stable.rst | 13 ++
> Documentation/admin-guide/abi-testing.rst | 19 +++
> Documentation/admin-guide/abi.rst | 11 ++
> Documentation/admin-guide/index.rst | 1 +
> Documentation/conf.py | 2 +-
> Documentation/sphinx/kernel_abi.py | 155 +++++++++++++++++++++
> 8 files changed, 214 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/admin-guide/abi-obsolete.rst
> create mode 100644 Documentation/admin-guide/abi-removed.rst
> create mode 100644 Documentation/admin-guide/abi-stable.rst
> create mode 100644 Documentation/admin-guide/abi-testing.rst
> create mode 100644 Documentation/admin-guide/abi.rst
> create mode 100644 Documentation/sphinx/kernel_abi.py
>
> diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst
> new file mode 100644
> index 000000000000..cda9168445a5
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-obsolete.rst
> @@ -0,0 +1,10 @@
> +ABI obsolete symbols
> +====================
> +
> +Documents interfaces that are still remaining in the kernel, but are
> +marked to be removed at some later point in time.
> +
> +The description of the interface will document the reason why it is
> +obsolete and when it can be expected to be removed.
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/obsolete
> diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst
> new file mode 100644
> index 000000000000..497978fc9632
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-removed.rst
> @@ -0,0 +1,4 @@
> +ABI removed symbols
> +===================
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/removed
> diff --git a/Documentation/admin-guide/abi-stable.rst b/Documentation/admin-guide/abi-stable.rst
> new file mode 100644
> index 000000000000..7495d7a35048
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-stable.rst
> @@ -0,0 +1,13 @@
> +ABI stable symbols
> +==================
> +
> +Documents the interfaces that the developer has defined to be stable.
> +
> +Userspace programs are free to use these interfaces with no
> +restrictions, and backward compatibility for them will be guaranteed
> +for at least 2 years.
> +
> +Most interfaces (like syscalls) are expected to never change and always
> +be available.
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/stable
> diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst
> new file mode 100644
> index 000000000000..5c886fc50b9e
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-testing.rst
> @@ -0,0 +1,19 @@
> +ABI testing symbols
> +===================
> +
> +Documents interfaces that are felt to be stable,
> +as the main development of this interface has been completed.
> +
> +The interface can be changed to add new features, but the
> +current interface will not break by doing this, unless grave
> +errors or security problems are found in them.
> +
> +Userspace programs can start to rely on these interfaces, but they must
> +be aware of changes that can occur before these interfaces move to
> +be marked stable.
> +
> +Programs that use these interfaces are strongly encouraged to add their
> +name to the description of these interfaces, so that the kernel
> +developers can easily notify them if any changes occur.
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/testing
> diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst
> new file mode 100644
> index 000000000000..3b9645c77469
> --- /dev/null
> +++ b/Documentation/admin-guide/abi.rst
> @@ -0,0 +1,11 @@
> +=====================
> +Linux ABI description
> +=====================
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + abi-stable
> + abi-testing
> + abi-obsolete
> + abi-removed
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 8001917ee012..20c3020fd73c 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -16,6 +16,7 @@ etc.
> README
> kernel-parameters
> devices
> + abi
>
> This section describes CPU vulnerabilities and their mitigations.
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 7ace3f8852bd..598256fb5c98 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,7 @@ needs_sphinx = '1.3'
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig', 'kernel_abi']
>
> # The name of the math extension changed on Sphinx 1.4
> if (major == 1 and minor > 3) or (major > 1):
> diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
> new file mode 100644
> index 000000000000..32ce90775d96
> --- /dev/null
> +++ b/Documentation/sphinx/kernel_abi.py
> @@ -0,0 +1,155 @@
> +# -*- coding: utf-8; mode: python -*-
> +u"""
> + kernel-abi
> + ~~~~~~~~~~
> +
> + Implementation of the ``kernel-abi`` reST-directive.
> +
> + :copyright: Copyright (C) 2016 Markus Heiser
> + :copyright: Copyright (C) 2016 Mauro Carvalho Chehab
> + :license: GPL Version 2, June 1991 see Linux/COPYING for details.
> +
> + The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the
> + scripts/get_abi.pl script to parse the Kernel ABI files.
> +
> + Overview of directive's argument and options.
> +
> + .. code-block:: rst
> +
> + .. kernel-abi:: <ABI directory location>
> + :debug:
> +
> + The argument ``<ABI directory location>`` is required. It contains the
> + location of the ABI files to be parsed.
> +
> + ``debug``
> + Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
> + what reST is generated.
> +
> +"""
> +
> +import sys
> +import os
> +from os import path
> +import subprocess
> +
> +from sphinx.ext.autodoc import AutodocReporter
> +
> +from docutils import nodes
> +from docutils.parsers.rst import Directive, directives
> +from docutils.statemachine import ViewList
> +from docutils.utils.error_reporting import ErrorString
> +
> +
> +__version__ = '1.0'
> +
> +# We can't assume that six is installed
> +PY3 = sys.version_info[0] == 3
> +PY2 = sys.version_info[0] == 2
> +if PY3:
> + # pylint: disable=C0103, W0622
> + unicode = str
> + basestring = str
> +
> +def setup(app):
> +
> + app.add_directive("kernel-abi", KernelCmd)
> + return dict(
> + version = __version__
> + , parallel_read_safe = True
> + , parallel_write_safe = True
> + )
> +
> +class KernelCmd(Directive):
> +
> + u"""KernelABI (``kernel-abi``) directive"""
> +
> + required_arguments = 1
> + optional_arguments = 0
> + has_content = False
> + final_argument_whitespace = True
> +
> + option_spec = {
> + "debug" : directives.flag
> + }
> +
> + def warn(self, message, **replace):
> + replace["fname"] = self.state.document.current_source
> + replace["line_no"] = replace.get("line_no", self.lineno)
> + message = ("%(fname)s:%(line_no)s: [kernel-abi WARN] : " + message) % replace
> + self.state.document.settings.env.app.warn(message, prefix="")
> +
> + def run(self):
> +
> + doc = self.state.document
> + if not doc.settings.file_insertion_enabled:
> + raise self.warning("docutils: file insertion disabled")
> +
> + env = doc.settings.env
> + cwd = path.dirname(doc.current_source)
> + cmd = "get_abi.pl rest --dir "
> + cmd += self.arguments[0]
> +
> + srctree = path.abspath(os.environ["srctree"])
> +
> + fname = cmd
> +
> + # extend PATH with $(srctree)/scripts
> + path_env = os.pathsep.join([
> + srctree + os.sep + "scripts",
> + os.environ["PATH"]
> + ])
> + shell_env = os.environ.copy()
> + shell_env["PATH"] = path_env
> + shell_env["srctree"] = srctree
> +
> + lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
> + nodeList = self.nestedParse(lines, fname)
> + return nodeList
> +
> + def runCmd(self, cmd, **kwargs):
> + u"""Run command ``cmd`` and return it's stdout as unicode."""
> +
> + try:
> + proc = subprocess.Popen(
> + cmd
> + , stdout = subprocess.PIPE
> + , stderr = subprocess.PIPE
> + , universal_newlines = True
> + , **kwargs
> + )
> + out, err = proc.communicate()
> + if err:
> + self.warn(err)
> + if proc.returncode != 0:
> + raise self.severe(
> + u"command '%s' failed with return code %d"
> + % (cmd, proc.returncode)
> + )
> + except OSError as exc:
> + raise self.severe(u"problems with '%s' directive: %s."
> + % (self.name, ErrorString(exc)))
> + return unicode(out)
> +
> + def nestedParse(self, lines, fname):
> + content = ViewList()
> + node = nodes.section()
> +
> + if "debug" in self.options:
> + code_block = "\n\n.. code-block:: rst\n :linenos:\n"
> + for l in lines.split("\n"):
> + code_block += "\n " + l
> + lines = code_block + "\n\n"
> +
> + for c, l in enumerate(lines.split("\n")):
> + content.append(l, fname, c)
> +
> + buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
> + self.state.memo.title_styles = []
> + self.state.memo.section_level = 0
> + self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter)
> + try:
> + self.state.nested_parse(content, 0, node, match_titles=1)
> + finally:
> + self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
> + return node.children
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Greg Kroah-Hartman @ 2019-06-14 13:39 UTC (permalink / raw)
To: Jani Nikula
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87r27wuwc3.fsf@intel.com>
On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >
> > Add a script to parse the Documentation/ABI files and produce
> > an output with all entries inside an ABI (sub)directory.
> >
> > Right now, it outputs its contents on ReST format. It shouldn't
> > be hard to make it produce other kind of outputs, since the ABI
> > file parser is implemented in separate than the output generator.
>
> Hum, or just convert the ABI files to rst directly.
And what would that look like?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Jani Nikula @ 2019-06-14 14:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190614133933.GA1076@kroah.com>
On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
>> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>> >
>> > Add a script to parse the Documentation/ABI files and produce
>> > an output with all entries inside an ABI (sub)directory.
>> >
>> > Right now, it outputs its contents on ReST format. It shouldn't
>> > be hard to make it produce other kind of outputs, since the ABI
>> > file parser is implemented in separate than the output generator.
>>
>> Hum, or just convert the ABI files to rst directly.
>
> And what would that look like?
That pretty much depends on the requirements we want to set on both the
ABI source files and the generated output. Obviously the requirements
can be conflicting; might be hard to produce fancy output if the input
is very limited.
At the bare minimum, you could convert the files to contain
reStructuredText field lists [1]. Add a colon at the start of the field
name, and make sure field bodies (values) are not empty.
Conversion of a file selected at random; I've only added ":" and "N/A".
diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu
index 33c133e2a631..34c218b344fb 100644
--- a/Documentation/ABI/stable/sysfs-devices-system-cpu
+++ b/Documentation/ABI/stable/sysfs-devices-system-cpu
@@ -1,19 +1,20 @@
-What: /sys/devices/system/cpu/dscr_default
-Date: 13-May-2014
-KernelVersion: v3.15.0
-Contact:
-Description: Writes are equivalent to writing to
+:What: /sys/devices/system/cpu/dscr_default
+:Date: 13-May-2014
+:KernelVersion: v3.15.0
+:Contact: N/A
+:Description: Writes are equivalent to writing to
/sys/devices/system/cpu/cpuN/dscr on all CPUs.
Reads return the last written value or 0.
This value is not a global default: it is a way to set
all per-CPU defaults at the same time.
-Values: 64 bit unsigned integer (bit field)
+:Values: 64 bit unsigned integer (bit field)
-What: /sys/devices/system/cpu/cpu[0-9]+/dscr
-Date: 13-May-2014
-KernelVersion: v3.15.0
-Contact:
-Description: Default value for the Data Stream Control Register (DSCR) on
+
+:What: /sys/devices/system/cpu/cpu[0-9]+/dscr
+:Date: 13-May-2014
+:KernelVersion: v3.15.0
+:Contact: N/A
+:Description: Default value for the Data Stream Control Register (DSCR) on
a CPU.
This default value is used when the kernel is executing and
for any process that has not set the DSCR itself.
@@ -22,4 +23,4 @@ Description: Default value for the Data Stream Control Register (DSCR) on
on any CPU where it executes (overriding the value described
here).
If set by a process it will be inherited by child processes.
-Values: 64 bit unsigned integer (bit field)
+:Values: 64 bit unsigned integer (bit field)
---
Of course, you'd still need to add higher level files to include the ABI
files.
At the other end, you could add structure and syntax to your heart's
content, and make the output fancier too.
BR,
Jani.
[1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#field-lists
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply related
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Mauro Carvalho Chehab @ 2019-06-14 13:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jani Nikula, Linux Doc Mailing List, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet
In-Reply-To: <20190614133933.GA1076@kroah.com>
Em Fri, 14 Jun 2019 15:39:33 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> > On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > >
> > > Add a script to parse the Documentation/ABI files and produce
> > > an output with all entries inside an ABI (sub)directory.
> > >
> > > Right now, it outputs its contents on ReST format. It shouldn't
> > > be hard to make it produce other kind of outputs, since the ABI
> > > file parser is implemented in separate than the output generator.
> >
> > Hum, or just convert the ABI files to rst directly.
Converting ABI files to rst could be easily done using a modified
version of my script (plus the produced files will likely need some
manual review).
There is a drawback though: we'll lose the capability of being able
to parse ABI files via an script, as people would be freed to use a
different syntax.
We could minimize it by using things like:
:What:
:Kernel Version:
...
> And what would that look like?
That's the big question :-)
If you prefer something like that, I can write the patches.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Greg Kroah-Hartman @ 2019-06-14 14:06 UTC (permalink / raw)
To: Jani Nikula
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87o930uvur.fsf@intel.com>
On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >
> > As we don't want a generic Sphinx extension to execute commands,
> > change the one proposed to Markus to call the abi_book.pl
> > script.
> >
> > Use a script to parse the Documentation/ABI directory and output
> > it at the admin-guide.
>
> We had a legacy kernel-doc perl script so we used that instead of
> rewriting it in python. Just to keep it bug-for-bug compatible with the
> past. That was the only reason.
>
> I see absolutely zero reason to add a new perl monstrosity with a python
> extension to call it. All of this could be better done in python,
> directly.
>
> Please don't complicate the documentation build. I know you know we all
> worked hard to take apart the old DocBook Rube Goldberg machine to
> replace it with Sphinx. Please don't turn the Sphinx build to another
> complicated mess.
>
> My strong preferences are, in this order:
>
> 1) Convert the ABI documentation to reStructuredText
What would that exactly look like? What would it require for new
developers for when they write new entries? Why not rely on a helper
script, that allows us to validate things better?
> 2) Have the python extension read the ABI files directly, without an
> extra pipeline.
He who writes the script, get's to dictate the language of the script :)
Personally, this looks sane to me, I'm going to apply the ABI fixups to
my tree at least, and then see how the script works out. The script can
always be replaced with a different one in a different language at a
later point in time of people think it really mattes.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Markus Heiser @ 2019-06-14 14:10 UTC (permalink / raw)
To: Jani Nikula, Mauro Carvalho Chehab, Linux Doc Mailing List,
Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87o930uvur.fsf@intel.com>
Am 14.06.19 um 15:42 schrieb Jani Nikula:
> On Thu, 13 Jun 2019, Mauro Carvalho Chehab<mchehab+samsung@kernel.org> wrote:
>> From: Mauro Carvalho Chehab<mchehab@s-opensource.com>
>>
>> As we don't want a generic Sphinx extension to execute commands,
>> change the one proposed to Markus to call the abi_book.pl
>> script.
>>
>> Use a script to parse the Documentation/ABI directory and output
>> it at the admin-guide.
> We had a legacy kernel-doc perl script so we used that instead of
> rewriting it in python. Just to keep it bug-for-bug compatible with the
> past. That was the only reason.
>
> I see absolutely zero reason to add a new perl monstrosity with a python
> extension to call it. All of this could be better done in python,
> directly.
>
> Please don't complicate the documentation build. I know you know we all
> worked hard to take apart the old DocBook Rube Goldberg machine to
> replace it with Sphinx. Please don't turn the Sphinx build to another
> complicated mess.
>
> My strong preferences are, in this order:
>
> 1) Convert the ABI documentation to reStructuredText
>
> 2) Have the python extension read the ABI files directly, without an
> extra pipeline.
>
I agree with Jani. No matter how the decision ends, since I can't help here, I'd
rather not show up in the copyright.
-- Markus --
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Jonathan Corbet @ 2019-06-14 14:14 UTC (permalink / raw)
To: Jani Nikula
Cc: Greg Kroah-Hartman, Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <87lfy4uuzs.fsf@intel.com>
On Fri, 14 Jun 2019 17:00:55 +0300
Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> >> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> >> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >> >
> >> > Add a script to parse the Documentation/ABI files and produce
> >> > an output with all entries inside an ABI (sub)directory.
> >> >
> >> > Right now, it outputs its contents on ReST format. It shouldn't
> >> > be hard to make it produce other kind of outputs, since the ABI
> >> > file parser is implemented in separate than the output generator.
> >>
> >> Hum, or just convert the ABI files to rst directly.
> >
> > And what would that look like?
>
> That pretty much depends on the requirements we want to set on both the
> ABI source files and the generated output. Obviously the requirements
> can be conflicting; might be hard to produce fancy output if the input
> is very limited.
The real question, I guess, is: is there anything else that depends on the
current format of those files? That could make reformatting them harder.
Otherwise it seems like Jani's fieldlist idea might have some potential.
We could consider a *really* simple preprocessing step if we really wanted
("prepend a colon on relevant lines and join with the following line if
need be") to keep the current format nearly unchanged.
jon
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Jonathan Corbet @ 2019-06-14 14:15 UTC (permalink / raw)
To: Markus Heiser
Cc: Jani Nikula, Mauro Carvalho Chehab, Linux Doc Mailing List,
Greg Kroah-Hartman, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
linux-kernel
In-Reply-To: <2955920a-3d6a-8e41-e8fe-b7db3cefed8b@darmarit.de>
On Fri, 14 Jun 2019 16:10:31 +0200
Markus Heiser <markus.heiser@darmarit.de> wrote:
> I agree with Jani. No matter how the decision ends, since I can't help here, I'd
> rather not show up in the copyright.
Is there something specific you are asking us to do here?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] Add a document on rebasing and merging
From: Jonathan Corbet @ 2019-06-14 14:25 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: open list:DOCUMENTATION, LKML, Theodore Ts'o,
Geert Uytterhoeven, David Rientjes, Jani Nikula, Michael Ellerman
In-Reply-To: <CACT4Y+avfTeZTmhti=7nEadthZZpTnOCTdEuG2S7PovmAMkhZQ@mail.gmail.com>
On Fri, 14 Jun 2019 11:59:03 +0200
Dmitry Vyukov <dvyukov@google.com> wrote:
> I will appreciate if you elaborate a bit on this "scale of the
> project". I wondered about reasons for having the current hierarchy of
> trees and complex merging for a while, but wasn't able to find any
> rationale. What exactly scale do you mean? I know a number of projects
> that are comparable to Linux kernel, with the largest being 2 orders
> of magnitude larger than kernel both in terms of code size and rate of
> change, that use single tree and linear history.
I'm not sure what projects you're talking about, so it's hard to compare.
During the 5.2 merge window, Linus did 209 pulls, bringing in just over
12,000 changesets, from on the order of 1600 developers. Even if, at the
beginning of the window, each of those pulls was set up to be a
fast-forward, they would no longer be positioned that way once the first
pull was done.
Are you really saying that subsystem maintainers should be continuously
rebasing their trees to avoid merges at the top level? Do you see how
much work that would take, how badly it would obscure the development
history, and how many bugs it would introduce? Or perhaps I misunderstood
what you're arguing for?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/9] media: docs: v4l2-controls: fix sentence rendered in a nonsense way
From: Luca Ceresoli @ 2019-06-14 15:16 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: Mauro Carvalho Chehab, linux-kernel, linux-doc
In-Reply-To: <069ac18c-7b9e-652a-1ff8-35fca09e6538@xs4all.nl>
Hi Hans,
On 14/06/19 09:14, Hans Verkuil wrote:
> On 6/13/19 4:18 PM, Luca Ceresoli wrote:
>> This sentence renders as:
>>
>>> Since such compound controls need to expose more information about
>>> themselves than is possible with ioctls VIDIOC_QUERYCTRL,
>>> VIDIOC_QUERY_EXT_CTRL and VIDIOC_QUERYMENU the VIDIOC_QUERY_EXT_CTRL
>> ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
>>> ioctl was added.
>>
>> This does not make sense. Fix by providing an explicit link text. This
>> results in:
>>
>>> Since such compound controls need to expose more information about
>>> themselves than is possible with VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU
>>> the VIDIOC_QUERY_EXT_CTRL ioctl was added.
>>
>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>> ---
>> Documentation/media/uapi/v4l/extended-controls.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
>> index 24274b398e63..0968aa9cd167 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -86,7 +86,7 @@ with compound types should only be used programmatically.
>>
>> Since such compound controls need to expose more information about
>> themselves than is possible with
>> -:ref:`VIDIOC_QUERYCTRL` the
>> +:ref:`VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` the
>
> This should just refer to VIDIOC_QUERYCTRL, not QUERYMENU. So this
> becomes: :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
Thanks for your prompt review. v2 on its way with this patch only, since
you already added the other ones in your latest pull request.
--
Luca
^ permalink raw reply
* [PATCH v2] media: docs: v4l2-controls: fix sentence rendered in a nonsense way
From: Luca Ceresoli @ 2019-06-14 15:14 UTC (permalink / raw)
To: linux-media
Cc: Luca Ceresoli, Mauro Carvalho Chehab, Hans Verkuil, linux-kernel,
linux-doc
This sentence renders as:
> Since such compound controls need to expose more information about
> themselves than is possible with ioctls VIDIOC_QUERYCTRL,
> VIDIOC_QUERY_EXT_CTRL and VIDIOC_QUERYMENU the VIDIOC_QUERY_EXT_CTRL
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
> ioctl was added.
This does not make sense. Fix by providing an explicit link text. This
results in:
> Since such compound controls need to expose more information about
> themselves than is possible with VIDIOC_QUERYCTRL the
> VIDIOC_QUERY_EXT_CTRL ioctl was added.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Documentation/media/uapi/v4l/extended-controls.rst | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 0e9787072a41..655362483730 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -85,11 +85,10 @@ be able to see such compound controls. In other words, these controls
with compound types should only be used programmatically.
Since such compound controls need to expose more information about
-themselves than is possible with
-:ref:`VIDIOC_QUERYCTRL` the
-:ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
-particular, this ioctl gives the dimensions of the N-dimensional array
-if this control consists of more than one element.
+themselves than is possible with :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
+the :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
+particular, this ioctl gives the dimensions of the N-dimensional array if
+this control consists of more than one element.
.. note::
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Mauro Carvalho Chehab @ 2019-06-14 15:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jani Nikula, Linux Doc Mailing List, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet
In-Reply-To: <20190614140603.GB7234@kroah.com>
Em Fri, 14 Jun 2019 16:06:03 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
> > On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > >
> > > As we don't want a generic Sphinx extension to execute commands,
> > > change the one proposed to Markus to call the abi_book.pl
> > > script.
> > >
> > > Use a script to parse the Documentation/ABI directory and output
> > > it at the admin-guide.
> >
> > We had a legacy kernel-doc perl script so we used that instead of
> > rewriting it in python. Just to keep it bug-for-bug compatible with the
> > past. That was the only reason.
> >
> > I see absolutely zero reason to add a new perl monstrosity with a python
> > extension to call it. All of this could be better done in python,
> > directly.
> >
> > Please don't complicate the documentation build. I know you know we all
> > worked hard to take apart the old DocBook Rube Goldberg machine to
> > replace it with Sphinx. Please don't turn the Sphinx build to another
> > complicated mess.
> >
> > My strong preferences are, in this order:
> >
> > 1) Convert the ABI documentation to reStructuredText
>
> What would that exactly look like? What would it require for new
> developers for when they write new entries? Why not rely on a helper
> script, that allows us to validate things better?
Funny enough, this e-mail arrived here after Greg's reply, and my
reply over his one :-)
-
With regards to the script, my idea is to have it run on a new
"validate" mode, when the Kernel is built with COMPILE_TEST:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=abi_patches_v4
NB: the last patch is not yet... somehow, the building system is not
passing CONFIG_WARN_ABI_ERRORS to Documentation/Makefile. I'm
debugging it.
Personally, I would prefer to keep it the way it is, with two
additions:
1) I would add a SPDX header at the fist line of each file there;
2) It would make sense to have a new field - or indicator - to let
add ReST markups at the description.
The advantage of using a parseable ABI file is that it is possible
to parse it, for example, to search for a symbol:
$ ./scripts/get_abi.pl voltage_max
/sys/class/power_supply/<supply_name>/voltage_max
-------------------------------------------------
Date: January 2008
Contact: linux-pm@vger.kernel.org
Defined on file: Documentation/ABI/testing/sysfs-class-power
Description:
Reports the maximum VBUS voltage the supply can support.
Access: Read
Valid values: Represented in microvolts
...
>
> > 2) Have the python extension read the ABI files directly, without an
> > extra pipeline.
>
> He who writes the script, get's to dictate the language of the script :)
No idea about how much time it would take if written in python,
but this perl script is really fast:
$ time ./scripts/get_abi.pl search voltage_max >/dev/null
real 0m0,139s
user 0m0,132s
sys 0m0,006s
That's the time it takes here (SSD disks) to read all files under
Documentation/ABI, parse them and seek for a string.
That's about half of the time a python script takes to just import the
the sphinx modules and print its version, running at the same machine:
$ time sphinx-build --version >/dev/null
real 0m0,224s
user 0m0,199s
sys 0m0,024s
> Personally, this looks sane to me, I'm going to apply the ABI fixups to
> my tree at least, and then see how the script works out. The script can
> always be replaced with a different one in a different language at a
> later point in time of people think it really mattes.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-14 15:25 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <ea5e333f-8cd6-8396-635f-a9dc580d5364@intel.com>
On Mon, 2019-06-10 at 15:59 -0700, Dave Hansen wrote:
> On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
> > Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
> > VM_DONTDUMP. The bitmap will cover only 48-bit address space.
>
> Could you make sure to discuss the downsides of only doing a 48-bit
> address space?
The downside is that we cannot load legacy lib's above 48-bit address space, but
currently ld-linux does not do that. Should ld-linux do that in the future,
dlopen() fails. Considering CRIU migration, we probably need to do this anyway?
> What are the reasons behind and implications of VM_DONTDUMP?
The bitmap is very big.
In GDB, it should be easy to tell why a control-protection fault occurred
without the bitmap.
Yu-cheng
^ permalink raw reply
* Re: [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
From: Jarkko Sakkinen @ 2019-06-14 15:36 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, Ard Biesheuvel,
Daniel Thompson, linux-doc, Linux Kernel Mailing List, tee-dev
In-Reply-To: <CAFA6WYP7qi_NBRUDBhcEAEzJY-iFvJdXqtCtgQxqAvPSXDjEng@mail.gmail.com>
On Fri, Jun 14, 2019 at 11:07:23AM +0530, Sumit Garg wrote:
> On Thu, 13 Jun 2019 at 21:04, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Thu, Jun 13, 2019 at 04:00:32PM +0530, Sumit Garg wrote:
> > > Provide documentation for usage of TEE based Trusted Keys via existing
> > > user-space "keyctl" utility. Also, document various use-cases.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > Sorry missed this patch. Anyway, I don't think we want multiple trusted
> > keys subsystems. You have to fix the existing one if you care to get
> > these changes in. There is no really other way around this.
> >
>
> I understand your point.
>
> When I initially looked at trusted key implementation, it seemed to be
> tightly coupled to use TPM device. So I implemented a parallel
> implementation to get initial feedback (functionality-wise) on this
> new approach.
Yeah, I completely get this. My feedback this is: we can definitely
consider TEE based trusted keys, and I know that trusted.ko is a mess,
but still that is the only right long-term path. Think about the
positive side: if you as a side-effect can make it cleaner and more
versatile, your patch set will improve the quality of the kernel as a
whole i.e. you benefit larger audience than just TEE user base :-)
> I will work on abstraction of trusted key apis to use either approach.
> But is it fine with you if I send if I send a separate RFC patch for
> abstraction and later once reviewed I will incorporate that patch in
> this patch-set.
>
> It will be really helpful if you could help to test that abstraction
> patch with a real TPM device as I doesn't posses one to test.
I can, yes.
/Jarkko
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-14 16:13 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <cf0d1470e95e0a8b88742651d06601a53d6655c1.camel@intel.com>
On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
> On Mon, 2019-06-10 at 15:59 -0700, Dave Hansen wrote:
>> On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
>>> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
>>> VM_DONTDUMP. The bitmap will cover only 48-bit address space.
>>
>> Could you make sure to discuss the downsides of only doing a 48-bit
>> address space?
>
> The downside is that we cannot load legacy lib's above 48-bit address space, but
> currently ld-linux does not do that. Should ld-linux do that in the future,
> dlopen() fails. Considering CRIU migration, we probably need to do this anyway?
Again, I was thinking about JITs. Please remember that not all code in
the system is from files on the disk. Please. We need to be really,
really sure that we don't addle this implementation by being narrow
minded about this.
Please don't forget about JITs.
>> What are the reasons behind and implications of VM_DONTDUMP?
>
> The bitmap is very big.
Really? It's actually, what, 8*4096=32k, so 1/32,768th of the size of
the libraries legacy libraries you load? Do our crash dumps really not
know how to represent or deal with sparse mappings?
> In GDB, it should be easy to tell why a control-protection fault occurred
> without the bitmap.
How about why one didn't happen?
^ permalink raw reply
* Re: [PATCH 01/14] ABI: fix some syntax issues at the ABI database
From: Greg Kroah-Hartman @ 2019-06-14 16:16 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Andreas Klinger, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Frederic Barrat, Sebastian Reichel, Kees Cook, Anton Vorontsov,
Colin Cross, Tony Luck, linux-iio, linuxppc-dev, linux-pm
In-Reply-To: <1ef7b765-da34-c65b-a226-f17969935ce2@linux.ibm.com>
On Fri, Jun 14, 2019 at 05:20:29PM +1000, Andrew Donnellan wrote:
> On 14/6/19 12:04 pm, Mauro Carvalho Chehab wrote:
> > diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
> > index bbbabffc682a..fc7c6f7c21b3 100644
> > --- a/Documentation/ABI/testing/sysfs-class-cxl
> > +++ b/Documentation/ABI/testing/sysfs-class-cxl
> > @@ -1,6 +1,6 @@
> > -Note: Attributes that are shared between devices are stored in the directory
> > -pointed to by the symlink device/.
> > -Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
> > +Please notice that attributes that are shared between devices are stored in
>
> Would prefer "Please note" over "Please notice".
Now changed, but that's a minor grammer thing, both are correct. :)
> Acked-by: Andrew Donnellan <ajd@linux.ibm.com> # cxl
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 14/14] docs: sphinx/kernel_abi.py: fix UTF-8 support
From: Greg Kroah-Hartman @ 2019-06-14 16:18 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <62c8ffe86df40c90299e80619a1cb5d50971c2c6.1560477540.git.mchehab+samsung@kernel.org>
On Thu, Jun 13, 2019 at 11:04:20PM -0300, Mauro Carvalho Chehab wrote:
> The parser breaks with UTF-8 characters with Sphinx 1.4.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/sphinx/kernel_abi.py | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
> index 7fa7806532dc..460cee48a245 100644
> --- a/Documentation/sphinx/kernel_abi.py
> +++ b/Documentation/sphinx/kernel_abi.py
> @@ -1,4 +1,5 @@
> -# -*- coding: utf-8; mode: python -*-
> +# coding=utf-8
> +#
Is this an emacs vs. vim fight?
Why change this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 00/14] Add support to generate ABI documentation at admin-guide
From: Greg Kroah-Hartman @ 2019-06-14 16:20 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, linuxppc-dev, Andrew Donnellan, Jonathan Cameron,
Lars-Peter Clausen, Anton Vorontsov, linux-pm, Colin Cross,
linux-iio, Hartmut Knaack, Sebastian Reichel, Frederic Barrat,
Andreas Klinger, Tony Luck, Peter Meerwald-Stadler, Stefan Achatz,
Kees Cook
In-Reply-To: <cover.1560477540.git.mchehab+samsung@kernel.org>
On Thu, Jun 13, 2019 at 11:04:06PM -0300, Mauro Carvalho Chehab wrote:
> Greg,
>
> As promised, I'm resending the patch series with adds the Kernel ABI to
> Documentation/admin-guide.
>
> Those patches are basically the version 3 patchset I sent back in 2017,
> rebased on the top of linux-next (next-20190613), and with some fixes
> in order for it to work.
>
> - The 4 initial patches to fix some ABI descriptions that are violating
> the syntax described at Documentation/ABI/README;
These 4 are now applied to my driver-core tree, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Greg Kroah-Hartman @ 2019-06-14 16:24 UTC (permalink / raw)
To: Jani Nikula
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87lfy4uuzs.fsf@intel.com>
On Fri, Jun 14, 2019 at 05:00:55PM +0300, Jani Nikula wrote:
> On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> >> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> >> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >> >
> >> > Add a script to parse the Documentation/ABI files and produce
> >> > an output with all entries inside an ABI (sub)directory.
> >> >
> >> > Right now, it outputs its contents on ReST format. It shouldn't
> >> > be hard to make it produce other kind of outputs, since the ABI
> >> > file parser is implemented in separate than the output generator.
> >>
> >> Hum, or just convert the ABI files to rst directly.
> >
> > And what would that look like?
>
> That pretty much depends on the requirements we want to set on both the
> ABI source files and the generated output. Obviously the requirements
> can be conflicting; might be hard to produce fancy output if the input
> is very limited.
>
> At the bare minimum, you could convert the files to contain
> reStructuredText field lists [1]. Add a colon at the start of the field
> name, and make sure field bodies (values) are not empty.
>
> Conversion of a file selected at random; I've only added ":" and "N/A".
N/A should be allowed to just drop the line entirely, right?
And what does this end up looking like?
I also hate "flag days" where all of a chunk of stuff needs to be
converted into another style. Also it doesn't deal with merges from the
100+ different trees that all end up adding stuff to this directory over
time (slowly though, unfortunately)
So ideally, I'd like to keep the original format if at all possible.
Having the tool here allows people to do nice things like search for a
specific file easily, or a device type, which is something that I know I
have wanted, and others have asked for in the past as well.
It also might allow us to find out where we are missing documentation, a
long-term goal of mine.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 14/14] docs: sphinx/kernel_abi.py: fix UTF-8 support
From: Mauro Carvalho Chehab @ 2019-06-14 16:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190614161837.GA25206@kroah.com>
Em Fri, 14 Jun 2019 18:18:37 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Thu, Jun 13, 2019 at 11:04:20PM -0300, Mauro Carvalho Chehab wrote:
> > The parser breaks with UTF-8 characters with Sphinx 1.4.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/sphinx/kernel_abi.py | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
> > index 7fa7806532dc..460cee48a245 100644
> > --- a/Documentation/sphinx/kernel_abi.py
> > +++ b/Documentation/sphinx/kernel_abi.py
> > @@ -1,4 +1,5 @@
> > -# -*- coding: utf-8; mode: python -*-
> > +# coding=utf-8
> > +#
>
> Is this an emacs vs. vim fight?
No. This is a python-specific thing:
https://www.python.org/dev/peps/pep-0263/
>
> Why change this?
Just to keep the "header" part of the script closer to kerneldoc.py.
You may keep the previous syntax if you want, as both ways are
equally recognized, as python actually checks for anything that
matches this regex at the first or second line:
^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)
Thanks,
Mauro
^ permalink raw reply
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