* Re: [PATCH] Documentation/features/locking: update lists
From: Jonathan Corbet @ 2019-07-26 20:45 UTC (permalink / raw)
To: Mark Rutland; +Cc: linux-kernel, linux-doc
In-Reply-To: <20190723132203.51814-1-mark.rutland@arm.com>
On Tue, 23 Jul 2019 14:22:03 +0100
Mark Rutland <mark.rutland@arm.com> wrote:
> The locking feature lists don't match reality as of v5.3-rc1:
>
> * arm64 moved to queued spinlocks in commit:
>
> c11090474d70590170cf5fa6afe85864ab494b37
>
> ("arm64: locking: Replace ticket lock implementation with qspinlock")
>
> * xtensa moved to queued spinlocks and rwlocks in commit:
>
> 579afe866f52adcd921272a224ab36733051059c
>
> ("xtensa: use generic spinlock/rwlock implementation")
>
> * architecture-specific rwsem support was removed in commit:
>
> 46ad0840b1584b92b5ff2cc3ed0b011dd6b8e0f1
>
> ("locking/rwsem: Remove arch specific rwsem files")
>
> So update the feature lists accordingly, and remove the now redundant
> rwsem-optimized list.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: filesystem: fix "Removed Sysctls" table
From: Jonathan Corbet @ 2019-07-26 20:51 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, linux-kernel-mentees, Darrick J. Wong, linux-xfs,
open list:DOCUMENTATION, open list
In-Reply-To: <20190723114813.GA14870@localhost>
On Tue, 23 Jul 2019 12:48:13 +0100
Sheriff Esseson <sheriffesseson@gmail.com> wrote:
> the "Removed Sysctls" section is a table - bring it alive with ReST.
>
> Signed-off-by: Sheriff Esseson <sheriffesseson@gmail.com>
> ---
> Documentation/admin-guide/xfs.rst | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst
> index e76665a8f2f2..fb5b39f73059 100644
> --- a/Documentation/admin-guide/xfs.rst
> +++ b/Documentation/admin-guide/xfs.rst
> @@ -337,11 +337,12 @@ None at present.
> Removed Sysctls
> ===============
>
> +============================= =======
> Name Removed
> - ---- -------
> +============================= =======
> fs.xfs.xfsbufd_centisec v4.0
> fs.xfs.age_buffer_centisecs v4.0
> -
> +============================= =======
I've applied this, thanks.
jon
^ permalink raw reply
* Re: [PATCH 0/7] Fix broken references to files under Documentation/*
From: Mauro Carvalho Chehab @ 2019-07-26 21:01 UTC (permalink / raw)
To: Atish Patra
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Łukasz Stelmach, Rob Herring
In-Reply-To: <57eaa99a-d644-7b79-7177-a45d3ef1e71a@wdc.com>
Em Fri, 26 Jul 2019 13:18:30 -0700
Atish Patra <atish.patra@wdc.com> escreveu:
> On 7/26/19 1:14 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 26 Jul 2019 12:55:36 -0700
> > Atish Patra <atish.patra@wdc.com> escreveu:
> >
> >> On 7/26/19 4:47 AM, Mauro Carvalho Chehab wrote:
> >>> Solves most of the pending broken references upstream, except for two of
> >>> them:
> >>>
> >>> $ ./scripts/documentation-file-ref-check
> >>> Documentation/riscv/boot-image-header.txt: Documentation/riscv/booting.txt
> >>> MAINTAINERS: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
> >>>
> >>> As written at boot-image-header.txt, it is waiting for the addition of
> >>> a future file:
> >>>
> >>> "The complete booting guide will be available at
> >>> Documentation/riscv/booting.txt."
> >>>
> >>
> >> Yeah. We don't have complete booting guide defined in RISC-V land.
> >> Documentation/riscv/booting.txt will be available once we have that.
> >>
> >> In the mean time, do we need to convert boot-image-header.txt to
> >> boot-image-header.rst and fix the reference to
> >> Documentation/riscv/booting.rst as well ?
> >
> > Well, in the mean time, every time someone builds the Kernel with
> > COMPILE_TEST enabled, a warning will be produced.
> >
> > So, my suggestion would be to write it on a different way, like:
> >
> > "A complete booting guide is being written and should be
> > available on future versions."
> >
> > Or:
> > TODO:
> > Write a complete booting guide.
> >
> > And update this once the guide is finished. This should be enough
> > to prevent the warning.
> >
>
> Sounds good to me.
>
> > With regards to converting it to ReST, that's recommended. I suspect
> > we could be able to finish the entire doc conversion in a couple
> > Kernel versions.
> >
> Sure.
>
> > Also, it should be really trivial to convert this one to ReST.
> >
>
> Yes. Let me know if you prefer to update it along with your series or I
> will send the patch.
I suspect it would be quicker if I write it. I'm sending it in a
few.
Thanks,
Mauro
^ permalink raw reply
* [PATCH] docs: riscv: convert boot-image-header.txt to ReST
From: Mauro Carvalho Chehab @ 2019-07-26 21:01 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Atish Patra, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Karsten Merker, Linus Walleij, linux-riscv
In-Reply-To: <57eaa99a-d644-7b79-7177-a45d3ef1e71a@wdc.com>
Convert this small file to ReST format by:
- Using a proper markup for the document title;
- marking a code block as such;
- use tags for Author and date;
- use tables for bit map fields.
While here, fix a broken reference for a document with is
planned but is not here yet.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
| 39 ++++++++++++-------
Documentation/riscv/index.rst | 1 +
2 files changed, 26 insertions(+), 14 deletions(-)
rename Documentation/riscv/{boot-image-header.txt => boot-image-header.rst} (72%)
diff --git a/Documentation/riscv/boot-image-header.txt b/Documentation/riscv/boot-image-header.rst
similarity index 72%
rename from Documentation/riscv/boot-image-header.txt
rename to Documentation/riscv/boot-image-header.rst
index 1b73fea23b39..43e9bd0731d5 100644
--- a/Documentation/riscv/boot-image-header.txt
+++ b/Documentation/riscv/boot-image-header.rst
@@ -1,22 +1,25 @@
- Boot image header in RISC-V Linux
- =============================================
+=================================
+Boot image header in RISC-V Linux
+=================================
-Author: Atish Patra <atish.patra@wdc.com>
-Date : 20 May 2019
+:Author: Atish Patra <atish.patra@wdc.com>
+: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.
+TODO:
+ Write a complete booting guide.
+
+The following 64-byte header is present in decompressed Linux kernel image::
u32 code0; /* Executable code */
- u32 code1; /* Executable code */
+ u32 code1; /* Executable code */
u64 text_offset; /* Image load offset, little endian */
u64 image_size; /* Effective Image size, little endian */
u64 flags; /* kernel flags, little endian */
u32 version; /* Version of this header */
- u32 res1 = 0; /* Reserved */
- u64 res2 = 0; /* Reserved */
+ u32 res1 = 0; /* Reserved */
+ u64 res2 = 0; /* Reserved */
u64 magic = 0x5643534952; /* Magic number, little endian, "RISCV" */
u32 res3; /* Reserved for additional RISC-V specific header */
u32 res4; /* Reserved for PE COFF offset */
@@ -25,16 +28,21 @@ 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:
+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
+- 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.
@@ -44,7 +52,10 @@ Notes:
extension for RISC-V in future. For current version, it is set to be zero.
- In current header, the flag field has only one field.
- Bit 0: Kernel endianness. 1 if BE, 0 if LE.
+
+ ===== ====================================
+ Bit 0 Kernel endianness. 1 if BE, 0 if LE.
+ ===== ====================================
- Image size is mandatory for boot loader to load kernel image. Booting will
fail otherwise.
diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index e3ca0922a8c2..215fd3c1f2d5 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -5,6 +5,7 @@ RISC-V architecture
.. toctree::
:maxdepth: 1
+ boot-image-header
pmu
.. only:: subproject and html
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] Documentation: move Documentation/virtual to Documentation/virt
From: Paolo Bonzini @ 2019-07-26 22:10 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Christoph Hellwig, rkrcmar, jdike, richard, anton.ivanov,
linux-doc, kvm, linux-um, linux-kernel
In-Reply-To: <20190724120005.31a990af@lwn.net>
On 24/07/19 20:00, Jonathan Corbet wrote:
> - kvm/api.txt pretty clearly belongs in the userspace-api book, rather
> than tossed in with:
>
> - kvm/review-checklist.txt, which belongs in the subsystem guide, if only
> we'd gotten around to creating it yet, or
>
> - kvm/mmu.txt, which is information for kernel developers, or
>
> - uml/UserModeLinux-HOWTO.txt, which belongs in the admin guide.
>
> I suspect that organization is going to be one of the main issues to talk
> about in Lisbon. Meanwhile, I hope that this rename won't preclude
> organizational work in the future.
Absolutely not, this rename was just about a badly-named directory. I
totally agree with the above reorganization. Does the userspace API
cover only syscall or perhaps sysfs interfaces? There are more API
files (amd-memory-encryption.txt, cpuid.txt, halt-polling.txt msr.txt,
ppc-pv.txt, s390-diag.txt) but, with the exception of
amd-memory-encryption.txt and halt-polling.txt, they cover the
emulated-hardware interfaces that KVM provides to virtual machines.
Paolo
^ permalink raw reply
* Re: [PATCH 0/7] Fix broken references to files under Documentation/*
From: Atish Patra @ 2019-07-26 22:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Łukasz Stelmach, Rob Herring
In-Reply-To: <20190726180109.56d1db35@coco.lan>
On 7/26/19 2:01 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 26 Jul 2019 13:18:30 -0700
> Atish Patra <atish.patra@wdc.com> escreveu:
>
>> On 7/26/19 1:14 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 26 Jul 2019 12:55:36 -0700
>>> Atish Patra <atish.patra@wdc.com> escreveu:
>>>
>>>> On 7/26/19 4:47 AM, Mauro Carvalho Chehab wrote:
>>>>> Solves most of the pending broken references upstream, except for two of
>>>>> them:
>>>>>
>>>>> $ ./scripts/documentation-file-ref-check
>>>>> Documentation/riscv/boot-image-header.txt: Documentation/riscv/booting.txt
>>>>> MAINTAINERS: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
>>>>>
>>>>> As written at boot-image-header.txt, it is waiting for the addition of
>>>>> a future file:
>>>>>
>>>>> "The complete booting guide will be available at
>>>>> Documentation/riscv/booting.txt."
>>>>>
>>>>
>>>> Yeah. We don't have complete booting guide defined in RISC-V land.
>>>> Documentation/riscv/booting.txt will be available once we have that.
>>>>
>>>> In the mean time, do we need to convert boot-image-header.txt to
>>>> boot-image-header.rst and fix the reference to
>>>> Documentation/riscv/booting.rst as well ?
>>>
>>> Well, in the mean time, every time someone builds the Kernel with
>>> COMPILE_TEST enabled, a warning will be produced.
>>>
>>> So, my suggestion would be to write it on a different way, like:
>>>
>>> "A complete booting guide is being written and should be
>>> available on future versions."
>>>
>>> Or:
>>> TODO:
>>> Write a complete booting guide.
>>>
>>> And update this once the guide is finished. This should be enough
>>> to prevent the warning.
>>>
>>
>> Sounds good to me.
>>
>>> With regards to converting it to ReST, that's recommended. I suspect
>>> we could be able to finish the entire doc conversion in a couple
>>> Kernel versions.
>>>
>> Sure.
>>
>>> Also, it should be really trivial to convert this one to ReST.
>>>
>>
>> Yes. Let me know if you prefer to update it along with your series or I
>> will send the patch.
>
> I suspect it would be quicker if I write it. I'm sending it in a
> few.
>
Thanks!!
> Thanks,
> Mauro
>
--
Regards,
Atish
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: kvm: Convert cpuid.txt to .rst
From: Paolo Bonzini @ 2019-07-26 22:19 UTC (permalink / raw)
To: Jonathan Corbet, Luke Nowakowski-Krijger
Cc: linux-kernel-mentees, rkrcmar, kvm, linux-doc, linux-kernel
In-Reply-To: <20190708142032.4fbd175e@lwn.net>
On 08/07/19 22:20, Jonathan Corbet wrote:
>>>> +:Author: Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
>>> I rather suspect that email address doesn't work these days.
>>>
>> No I guess it wont :). We would still keep this correct?
> There's nothing good that will come from keeping a broken email address
> there. You could either:
>
> - Just take the address out, or
I agree with this, there have been more authors since 2010.
Regarding the license, it was my understanding that if somebody wants
anything but GPL-2.0 they should put it in the file when they create it.
That's because even if Glauber had a different idea of what license to
use, other contributors to the file couldn't know.
Paolo
> - Track Glauber down and get a newer address; you could ask him about the
> licensing while you're at it :)
^ permalink raw reply
* Re: [PATCH] docs: riscv: convert boot-image-header.txt to ReST
From: Atish Patra @ 2019-07-26 22:24 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Albert Ou, Jonathan Corbet, Linus Walleij, Palmer Dabbelt,
linux-kernel@vger.kernel.org, Mauro Carvalho Chehab,
Paul Walmsley, linux-riscv@lists.infradead.org, Karsten Merker
In-Reply-To: <1eaeb3fbb74de55af0b3f6d93ab40776dcbbb5c8.1564174903.git.mchehab+samsung@kernel.org>
On 7/26/19 2:02 PM, Mauro Carvalho Chehab wrote:
> Convert this small file to ReST format by:
> - Using a proper markup for the document title;
> - marking a code block as such;
> - use tags for Author and date;
> - use tables for bit map fields.
>
> While here, fix a broken reference for a document with is
> planned but is not here yet.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> ...image-header.txt => boot-image-header.rst} | 39 ++++++++++++-------
> Documentation/riscv/index.rst | 1 +
> 2 files changed, 26 insertions(+), 14 deletions(-)
> rename Documentation/riscv/{boot-image-header.txt => boot-image-header.rst} (72%)
>
> diff --git a/Documentation/riscv/boot-image-header.txt b/Documentation/riscv/boot-image-header.rst
> similarity index 72%
> rename from Documentation/riscv/boot-image-header.txt
> rename to Documentation/riscv/boot-image-header.rst
> index 1b73fea23b39..43e9bd0731d5 100644
> --- a/Documentation/riscv/boot-image-header.txt
> +++ b/Documentation/riscv/boot-image-header.rst
> @@ -1,22 +1,25 @@
> - Boot image header in RISC-V Linux
> - =============================================
> +=================================
> +Boot image header in RISC-V Linux
> +=================================
>
> -Author: Atish Patra <atish.patra@wdc.com>
> -Date : 20 May 2019
> +:Author: Atish Patra <atish.patra@wdc.com>
> +: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.
> +TODO:
> + Write a complete booting guide.
> +
> +The following 64-byte header is present in decompressed Linux kernel image::
>
> u32 code0; /* Executable code */
> - u32 code1; /* Executable code */
> + u32 code1; /* Executable code */
> u64 text_offset; /* Image load offset, little endian */
> u64 image_size; /* Effective Image size, little endian */
> u64 flags; /* kernel flags, little endian */
> u32 version; /* Version of this header */
> - u32 res1 = 0; /* Reserved */
> - u64 res2 = 0; /* Reserved */
> + u32 res1 = 0; /* Reserved */
> + u64 res2 = 0; /* Reserved */
> u64 magic = 0x5643534952; /* Magic number, little endian, "RISCV" */
> u32 res3; /* Reserved for additional RISC-V specific header */
> u32 res4; /* Reserved for PE COFF offset */
> @@ -25,16 +28,21 @@ 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:
> +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
> +- 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.
> @@ -44,7 +52,10 @@ Notes:
> extension for RISC-V in future. For current version, it is set to be zero.
>
> - In current header, the flag field has only one field.
> - Bit 0: Kernel endianness. 1 if BE, 0 if LE.
> +
> + ===== ====================================
> + Bit 0 Kernel endianness. 1 if BE, 0 if LE.
> + ===== ====================================
>
> - Image size is mandatory for boot loader to load kernel image. Booting will
> fail otherwise.
> diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
> index e3ca0922a8c2..215fd3c1f2d5 100644
> --- a/Documentation/riscv/index.rst
> +++ b/Documentation/riscv/index.rst
> @@ -5,6 +5,7 @@ RISC-V architecture
> .. toctree::
> :maxdepth: 1
>
> + boot-image-header
> pmu
>
> .. only:: subproject and html
>
Thanks for the quick patch.
Reviewed-by: Atish Patra <atish.patra@wdc.com>
--
Regards,
Atish
^ permalink raw reply
* Re: [PATCH 2/7] docs: generic-counter.rst: fix broken references for ABI file
From: Jonathan Cameron @ 2019-07-27 12:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: William Breathitt Gray, Jonathan Corbet, linux-iio, linux-doc
In-Reply-To: <f55e1ef71a3a7194dacd3f0cecc0aa67aaffbd15.1564140865.git.mchehab+samsung@kernel.org>
On Fri, 26 Jul 2019 08:47:22 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> There are two references to the generic counter ABI, with was added
> on a separate patch. Both point to a non-existing file.
>
> Fix them.
>
> Fixes: ea2b23b89579 ("counter: Documentation: Add Generic Counter sysfs documentation")
> Fixes: 09e7d4ed8991 ("docs: Add Generic Counter interface documentation")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
> ---
> Documentation/driver-api/generic-counter.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
> index 0c161b1a3be6..8382f01a53e3 100644
> --- a/Documentation/driver-api/generic-counter.rst
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -233,7 +233,7 @@ Userspace Interface
> Several sysfs attributes are generated by the Generic Counter interface,
> and reside under the /sys/bus/counter/devices/counterX directory, where
> counterX refers to the respective counter device. Please see
> -Documentation/ABI/testing/sys-bus-counter-generic-sysfs for detailed
> +Documentation/ABI/testing/sysfs-bus-counter for detailed
> information on each Generic Counter interface sysfs attribute.
>
> Through these sysfs attributes, programs and scripts may interact with
> @@ -325,7 +325,7 @@ sysfs attributes, where Y is the unique ID of the respective Count:
>
> For a more detailed breakdown of the available Generic Counter interface
> sysfs attributes, please refer to the
> -Documentation/ABI/testing/sys-bus-counter file.
> +Documentation/ABI/testing/sysfs-bus-counter file.
>
> The Signals and Counts associated with the Counter device are registered
> to the system as well by the counter_register function. The
^ permalink raw reply
* Re: [PATCH] tools: memory-model: add it to the Documentation body
From: Joel Fernandes @ 2019-07-27 14:14 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Alan Stern, Andrea Parri, Will Deacon,
Peter Zijlstra, Boqun Feng, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Paul E. McKenney, Akira Yokosawa,
Daniel Lustig, Ingo Molnar, Jason Gunthorpe, SeongJae Park,
linux-arch
In-Reply-To: <5826090bf29ec831df620b79d7fe60ef7a705795.1564167643.git.mchehab+samsung@kernel.org>
On Fri, Jul 26, 2019 at 04:01:37PM -0300, Mauro Carvalho Chehab wrote:
> The books at tools/memory-model/Documentation are very well
> formatted. Congrats to the ones that wrote them!
>
> The manual conversion to ReST is really trivial:
>
> - Add document titles;
> - change the bullets on some lists;
> - mark code blocks.
Thanks so much, some feedback:
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
(1)
I could not find the table of contents appear in the HTML output for this.
Basically this list in the beginning doesn't render:
1. INTRODUCTION
2. BACKGROUND
3. A SIMPLE EXAMPLE
4. A SELECTION OF MEMORY MODELS
5. ORDERING AND CYCLES
Could we add a proper TOC with sections? My motivation for ReST here would be
to make the sections jumpable since it is a large document.
Also could we make the different sections appear as a tree in the left
sidebar?
(2) Arguably several function names in the document HTML output should appear
in monospace fonting and/or referring to the documentation for real function
names, but these can be fixed as we go, I guess.
(3) Things like smp_load_acquire() and spin_lock() should probably refer to
the documentation for those elsewhere..
(4) I would argue that every occurence of
A ->(some dependency) B should be replaced with fixed size font in the HTML
results.
Arguably it is better IMO if the whole document is fixed size font in the
HTML output because so many things need to be fixed size, but that my just be
my opinion.
thanks,
- Joel
> ---
> Documentation/core-api/refcount-vs-atomic.rst | 2 +-
> Documentation/index.rst | 1 +
> Documentation/tools/memory-model | 1 +
> .../memory-model/Documentation/cheatsheet.rst | 36 +++++
> .../memory-model/Documentation/cheatsheet.txt | 30 ----
> .../{explanation.txt => explanation.rst} | 151 ++++++++++--------
> tools/memory-model/Documentation/index.rst | 20 +++
> .../{recipes.txt => recipes.rst} | 41 ++---
> .../{references.txt => references.rst} | 46 +++---
> tools/memory-model/README | 10 +-
> 10 files changed, 192 insertions(+), 146 deletions(-)
> create mode 120000 Documentation/tools/memory-model
> create mode 100644 tools/memory-model/Documentation/cheatsheet.rst
> delete mode 100644 tools/memory-model/Documentation/cheatsheet.txt
> rename tools/memory-model/Documentation/{explanation.txt => explanation.rst} (97%)
> create mode 100644 tools/memory-model/Documentation/index.rst
> rename tools/memory-model/Documentation/{recipes.txt => recipes.rst} (96%)
> rename tools/memory-model/Documentation/{references.txt => references.rst} (71%)
^ permalink raw reply
* Re: [PATCH] tools: memory-model: add it to the Documentation body
From: Mauro Carvalho Chehab @ 2019-07-27 15:37 UTC (permalink / raw)
To: Joel Fernandes
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Alan Stern, Andrea Parri, Will Deacon,
Peter Zijlstra, Boqun Feng, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Paul E. McKenney, Akira Yokosawa,
Daniel Lustig, Ingo Molnar, Jason Gunthorpe, SeongJae Park,
linux-arch
In-Reply-To: <20190727141013.dpvjlcp3juja4see@penguin>
Em Sat, 27 Jul 2019 14:14:53 +0000
Joel Fernandes <joel@joelfernandes.org> escreveu:
> On Fri, Jul 26, 2019 at 04:01:37PM -0300, Mauro Carvalho Chehab wrote:
> > The books at tools/memory-model/Documentation are very well
> > formatted. Congrats to the ones that wrote them!
> >
> > The manual conversion to ReST is really trivial:
> >
> > - Add document titles;
> > - change the bullets on some lists;
> > - mark code blocks.
>
> Thanks so much, some feedback:
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> (1)
> I could not find the table of contents appear in the HTML output for this.
> Basically this list in the beginning doesn't render:
> 1. INTRODUCTION
> 2. BACKGROUND
> 3. A SIMPLE EXAMPLE
> 4. A SELECTION OF MEMORY MODELS
> 5. ORDERING AND CYCLES
Yes. It is written as a comment, like:
.. foo This is a comment block
Everything on this block
won't be parsed.
So it won't be parsed, but having a TOC like this isn't need, as
Sphinx generates it automatically via "toctree" markup.
> Could we add a proper TOC with sections? My motivation for ReST here would be
> to make the sections jumpable since it is a large document.
Just change the toctree depth at index.rst to 2 and you'll see an index
produced by Sphinx with both levels 1 (doc name) and level 2 (chapters):
.. toctree::
:maxdepth: 2
> Also could we make the different sections appear as a tree in the left
> sidebar?
The sidebar follows the maxdepth too.
>
> (2) Arguably several function names in the document HTML output should appear
> in monospace fonting and/or referring to the documentation for real function
> names, but these can be fixed as we go, I guess.
If you want monospaced fonts, just use: ``monospaced_symbol_foo`` within
any paragraph, or place the monospaced data inside a code-block:
::
This will be monospaced.
>
> (3) Things like smp_load_acquire() and spin_lock() should probably refer to
> the documentation for those elsewhere..
Jon added an automarkup extension on Kernel 5.2. So, all functions that
are defined elsewhere will automatically generate an hyperlink. For that to
happen, you need to add the kernel-doc markup at the *.h or *.c file where
the function is declared and use the kernel-doc markup somewhere within the
Kernel Documentation/.
>
> (4) I would argue that every occurence of
> A ->(some dependency) B should be replaced with fixed size font in the HTML
> results.
Just place those with ``A -> (some dependency)``. This will make them use
a fixed size font.
> Arguably it is better IMO if the whole document is fixed size font in the
> HTML output because so many things need to be fixed size, but that my just be
> my opinion.
Just my 2 cents here, but having the entire document using a fixed size
font makes it more boring to read. Having just the symbols with a fixed size
is a common convention used on technical books, and helps to make easier
to identify the symbols while reading the docs.
That's said, Sphinx doesn't have any tag to switch the font for the entire
document. All it can be done is to define a CSS and apply it for the
doc - or to place everything within a code-block, with will suppress all
markup tags, including cross-references for functions.
The problem with CSS is that you need to write both an html CSS file
and add LaTeX macros associated to this "CSS style" (technically, LaTeX
doesn't have a CSS concept, but Sphinx emulates it).
Thanks,
Mauro
^ permalink raw reply
* [PATCH v2] docs: admin-guide: Adjust title underline length
From: Fabio Estevam @ 2019-07-27 19:49 UTC (permalink / raw)
To: akpm; +Cc: sfr, corbet, mchehab+samsung, linux-doc, dima, Fabio Estevam
The following warning is seen when building 'make htmldocs':
Documentation/admin-guide/sysctl/kernel.rst:397: WARNING: Title underline too short.
Fix it by adjusting the title underline length appropriately.
Fixes: 725d8c9a2cc5 ("hung_task: allow printing warnings every check interval")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
Changes since v1:
- Added Fixes tag
- Sent to Andrew as the commit that generates the warning comes
from his tree (Jonathan)
Documentation/admin-guide/sysctl/kernel.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 2e36620ec1e4..8af424dd0364 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -394,7 +394,7 @@ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
hung_task_interval_warnings:
-===================
+============================
The same as hung_task_warnings, but set the number of interval
warnings to be issued about detected hung tasks during check
--
2.17.1
^ permalink raw reply related
* Re: [f2fs-dev] [PATCH v4 1/3] fs: Reserve flag for casefolding
From: Chao Yu @ 2019-07-28 0:36 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Chao Yu, Jonathan Corbet,
linux-f2fs-devel
Cc: linux-doc, linux-api, linux-kernel, linux-fsdevel, kernel-team
In-Reply-To: <20190723230529.251659-2-drosen@google.com>
On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
> In preparation for including the casefold feature within f2fs, elevate
> the EXT4_CASEFOLD_FL flag to FS_CASEFOLD_FL.
>
> Signed-off-by: Daniel Rosenberg <drosen@google.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v4 2/3] f2fs: include charset encoding information in the superblock
From: Chao Yu @ 2019-07-28 0:45 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Chao Yu, Jonathan Corbet,
linux-f2fs-devel
Cc: linux-doc, linux-api, linux-kernel, linux-fsdevel, kernel-team
In-Reply-To: <20190723230529.251659-3-drosen@google.com>
On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
> Add charset encoding to f2fs to support casefolding. It is modeled after
> the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
> encoding information in the superblock")
>
> Currently this is not compatible with encryption, similar to the current
> ext4 imlpementation. This will change in the future.
>
> From the ext4 patch:
> """
> The s_encoding field stores a magic number indicating the encoding
> format and version used globally by file and directory names in the
> filesystem. The s_encoding_flags defines policies for using the charset
> encoding, like how to handle invalid sequences. The magic number is
> mapped to the exact charset table, but the mapping is specific to ext4.
> Since we don't have any commitment to support old encodings, the only
> encoding I am supporting right now is utf8-12.1.0.
>
> The current implementation prevents the user from enabling encoding and
> per-directory encryption on the same filesystem at the same time. The
> incompatibility between these features lies in how we do efficient
> directory searches when we cannot be sure the encryption of the user
> provided fname will match the actual hash stored in the disk without
> decrypting every directory entry, because of normalization cases. My
> quickest solution is to simply block the concurrent use of these
> features for now, and enable it later, once we have a better solution.
> """
>
> Signed-off-by: Daniel Rosenberg <drosen@google.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Chao Yu @ 2019-07-28 0:55 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Chao Yu, Jonathan Corbet,
linux-f2fs-devel
Cc: linux-doc, linux-api, linux-kernel, linux-fsdevel, kernel-team
In-Reply-To: <20190723230529.251659-4-drosen@google.com>
On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
> /* Flags that are appropriate for regular files (all but dir-specific ones). */
> #define F2FS_REG_FLMASK (~(F2FS_DIRSYNC_FL | F2FS_PROJINHERIT_FL))
We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.
> @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
> return -EPERM;
>
> oldflags = fi->i_flags;
> + if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
> + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
> + return -EOPNOTSUPP;
> +
> + if (!S_ISDIR(inode->i_mode))
> + return -ENOTDIR;
>
> + if (!f2fs_empty_dir(inode))
> + return -ENOTEMPTY;
> + }
I applied the patches based on last Jaegeuk's dev branch, it seems we needs to
adjust above code a bit. Otherwise it looks good to me.
BTW, it looks the patchset works fine with generic/556 testcase.
Thanks,
^ permalink raw reply
* Re: general protection fault in tls_trim_both_msgs
From: syzbot @ 2019-07-28 3:46 UTC (permalink / raw)
To: ast, aviadye, borisp, bpf, corbet, daniel, davejwatson, davem,
jakub.kicinski, john.fastabend, kafai, linux-doc, linux-kernel,
netdev, songliubraving, syzkaller-bugs, yhs
In-Reply-To: <0000000000002b4896058e7abf78@google.com>
syzbot has bisected this bug to:
commit 32857cf57f920cdc03b5095f08febec94cf9c36b
Author: John Fastabend <john.fastabend@gmail.com>
Date: Fri Jul 19 17:29:18 2019 +0000
net/tls: fix transition through disconnect with close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=155064d8600000
start commit: fde50b96 Add linux-next specific files for 20190726
git tree: linux-next
final crash: https://syzkaller.appspot.com/x/report.txt?x=175064d8600000
console output: https://syzkaller.appspot.com/x/log.txt?x=135064d8600000
kernel config: https://syzkaller.appspot.com/x/.config?x=4b58274564b354c1
dashboard link: https://syzkaller.appspot.com/bug?extid=0e0fedcad708d12d3032
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14779d64600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1587c842600000
Reported-by: syzbot+0e0fedcad708d12d3032@syzkaller.appspotmail.com
Fixes: 32857cf57f92 ("net/tls: fix transition through disconnect with
close")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* [PATCH] doc:it_IT: translations for documents in process/
From: Federico Vaga @ 2019-07-28 9:20 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Federico Vaga, Alessia Mantegazza
From: Alessia Mantegazza <amantegazza@vaga.pv.it>
Translations for the following documents in process/:
- email-clients
- management-style
Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
.../it_IT/process/email-clients.rst | 328 +++++++++++++++++-
.../it_IT/process/management-style.rst | 290 +++++++++++++++-
2 files changed, 612 insertions(+), 6 deletions(-)
diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst
index 224ab031ffd3..fe579f063c73 100644
--- a/Documentation/translations/it_IT/process/email-clients.rst
+++ b/Documentation/translations/it_IT/process/email-clients.rst
@@ -1,12 +1,336 @@
.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/email-clients.rst <email_clients>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
.. _it_email_clients:
Informazioni sui programmi di posta elettronica per Linux
=========================================================
-.. warning::
+Git
+---
- TODO ancora da tradurre
+Oggigiorno, la maggior parte degli sviluppatori utilizza ``git send-email``
+al posto dei classici programmi di posta elettronica. Le pagine man sono
+abbastanza buone. Dal lato del ricevente, i manutentori utilizzano ``git am``
+per applicare le patch.
+
+Se siete dei novelli utilizzatori di ``git`` allora inviate la patch a voi
+stessi. Salvatela come testo includendo tutte le intestazioni. Poi eseguite
+il comando ``git am messaggio-formato-testo.txt`` e revisionatene il risultato
+con ``git log``. Quando tutto funziona correttamente, allora potete inviare
+la patch alla lista di discussione più appropriata.
+
+Panoramica delle opzioni
+------------------------
+
+Le patch per il kernel vengono inviate per posta elettronica, preferibilmente
+come testo integrante del messaggio. Alcuni manutentori accettano gli
+allegati, ma in questo caso gli allegati devono avere il *content-type*
+impostato come ``text/plain``. Tuttavia, generalmente gli allegati non sono
+ben apprezzati perché rende più difficile citare porzioni di patch durante il
+processo di revisione.
+
+I programmi di posta elettronica che vengono usati per inviare le patch per il
+kernel Linux dovrebbero inviarle senza alterazioni. Per esempio, non
+dovrebbero modificare o rimuovere tabulazioni o spazi, nemmeno all'inizio o
+alla fine delle righe.
+
+Non inviate patch con ``format=flowed``. Questo potrebbe introdurre
+interruzioni di riga inaspettate e indesiderate.
+
+Non lasciate che il vostro programma di posta vada a capo automaticamente.
+Questo può corrompere le patch.
+
+I programmi di posta non dovrebbero modificare la codifica dei caratteri nel
+testo. Le patch inviate per posta elettronica dovrebbero essere codificate in
+ASCII o UTF-8.
+Se configurate il vostro programma per inviare messaggi codificati con UTF-8
+eviterete possibili problemi di codifica.
+
+I programmi di posta dovrebbero generare e mantenere le intestazioni
+"References" o "In-Reply-To:" cosicché la discussione non venga interrotta.
+
+Di solito, il copia-e-incolla (o taglia-e-incolla) non funziona con le patch
+perché le tabulazioni vengono convertite in spazi. Usando xclipboard, xclip
+e/o xcutsel potrebbe funzionare, ma è meglio che lo verifichiate o meglio
+ancora: non usate il copia-e-incolla.
+
+Non usate firme PGP/GPG nei messaggi che contengono delle patch. Questo
+impedisce il corretto funzionamento di alcuni script per leggere o applicare
+patch (questo si dovrebbe poter correggere).
+
+Prima di inviare le patch sulle liste di discussione Linux, può essere una
+buona idea quella di inviare la patch a voi stessi, salvare il messaggio
+ricevuto, e applicarlo ai sorgenti con successo.
+
+
+Alcuni suggerimenti per i programmi di posta elettronica (MUA)
+--------------------------------------------------------------
+
+Qui troverete alcuni suggerimenti per configurare i vostri MUA allo scopo
+di modificare ed inviare patch per il kernel Linux. Tuttavia, questi
+suggerimenti non sono da considerarsi come un riassunto di una configurazione
+completa.
+
+Legenda:
+
+- TUI = interfaccia utente testuale (*text-based user interface*)
+- GUI = interfaccia utente grafica (*graphical user interface*)
+
+Alpine (TUI)
+************
+
+Opzioni per la configurazione:
+
+Nella sezione :menuselection:`Sending Preferences`:
+
+- :menuselection:`Do Not Send Flowed Text` deve essere ``enabled``
+- :menuselection:`Strip Whitespace Before Sending` deve essere ``disabled``
+
+Quando state scrivendo un messaggio, il cursore dev'essere posizionato
+dove volete che la patch inizi, poi premendo :kbd:`CTRL-R` vi verrà chiesto
+di selezionare il file patch da inserire nel messaggio.
+
+Claws Mail (GUI)
+****************
+
+Funziona. Alcune persone riescono ad usarlo con successo per inviare le patch.
+
+Per inserire una patch usate :menuselection:`Messaggio-->Inserisci file`
+(:kbd:`CTRL-I`) oppure un editor esterno.
+
+Se la patch che avete inserito dev'essere modificata usato la finestra di
+scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia
+disabilitata :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzione riga`.
+
+Evolution (GUI)
+***************
+
+Alcune persone riescono ad usarlo con successo per inviare le patch.
+
+Quando state scrivendo una lettera selezionate: Preformatttato
+ da :menuselection:`Formato-->Stile del paragrafo-->Preformattato`
+ (:kbd:`CTRL-7`) o dalla barra degli strumenti
+
+Poi per inserire la patch usate:
+:menuselection:`Inserisci--> File di testo...` (:kbd:`ALT-N x`)
+
+Potete anche eseguire ``diff -Nru old.c new.c | xclip``, selezionare
+:menuselection:`Preformattato`, e poi usare il tasto centrale del mouse.
+
+Kmail (GUI)
+***********
+
+Alcune persone riescono ad usarlo con successo per inviare le patch.
+
+La configurazione base che disabilita la composizione di messaggi HTML è
+corretta; non abilitatela.
+
+Quando state scrivendo un messaggio, nel menu opzioni, togliete la selezione a
+"A capo automatico". L'unico svantaggio sarà che qualsiasi altra cosa scriviate
+nel messaggio non verrà mandata a capo in automatico ma dovrete farlo voi.
+Il modo più semplice per ovviare a questo problema è quello di scrivere il
+messaggio con l'opzione abilitata e poi di salvarlo nelle bozze. Riaprendo ora
+il messaggio dalle bozze le andate a capo saranno parte integrante del
+messaggio, per cui togliendo l'opzione "A capo automatico" non perderete nulla.
+
+Alla fine del vostro messaggio, appena prima di inserire la vostra patch,
+aggiungete il delimitatore di patch: tre trattini (``---``).
+
+Ora, dal menu :menuselection:`Messaggio`, selezionate :menuselection:`Inserisci file di testo...`
+quindi scegliete la vostra patch.
+Come soluzione aggiuntiva potreste personalizzare la vostra barra degli
+strumenti aggiungendo un'icona per :menuselection:`Inserisci file di testo...`.
+
+Allargate la finestra di scrittura abbastanza da evitare andate a capo.
+Questo perché in Kmail 1.13.5 (KDE 4.5.4), Kmail aggiunge andate a capo
+automaticamente al momento dell'invio per tutte quelle righe che graficamente,
+nella vostra finestra di composizione, si sono estete su una riga successiva.
+Disabilitare l'andata a capo automatica non è sufficiente. Dunque, se la vostra
+patch contiene delle righe molto lunghe, allora dovrete allargare la finestra
+di composizione per evitare che quelle righe vadano a capo. Vedere:
+https://bugs.kde.org/show_bug.cgi?id=174034
+
+Potete firmare gli allegati con GPG, ma per le patch si preferisce aggiungerle
+al testo del messaggio per cui non usate la firma GPG. Firmare le patch
+inserite come testo del messaggio le rende più difficili da estrarre dalla loro
+codifica a 7-bit.
+
+Se dovete assolutamente inviare delle patch come allegati invece di integrarle
+nel testo del messaggio, allora premete il tasto destro sull'allegato e
+selezionate :menuselection:`Proprietà`, e poi attivate
+:menuselection:`Suggerisci visualizzazione automatica` per far si che
+l'allegato sia più leggibile venendo visualizzato come parte del messaggio.
+
+Per salvare le patch inviate come parte di un messaggio, selezionate il
+messaggio che la contiene, premete il tasto destro e selezionate
+:menuselection:`Salva come`. Se il messaggio fu ben preparato, allora potrete
+usarlo interamente senza alcuna modifica.
+I messaggi vengono salvati con permessi di lettura-scrittura solo per l'utente,
+nel caso in cui vogliate copiarli altrove per renderli disponibili ad altri
+gruppi o al mondo, ricordatevi di usare ``chmod`` per cambiare i permessi.
+
+Lotus Notes (GUI)
+*****************
+
+Scappate finché potete.
+
+IBM Verse (Web GUI)
+*******************
+
+Vedi il commento per Lotus Notes.
+
+Mutt (TUI)
+**********
+
+Un sacco di sviluppatori Linux usano ``mutt``, per cui deve funzionare
+abbastanza bene.
+
+Mutt non ha un proprio editor, quindi qualunque sia il vostro editor dovrete
+configurarlo per non aggiungere automaticamente le andate a capo. Molti
+editor hanno un'opzione :menuselection:`Inserisci file` che inserisce il
+contenuto di un file senza alterarlo.
+
+Per usare ``vim`` come editor per mutt::
+
+ set editor="vi"
+
+Se per inserire la patch nel messaggio usate xclip, scrivete il comando::
+
+ :set paste
+
+prima di premere il tasto centrale o shift-insert. Oppure usate il
+comando::
+
+ :r filename
+
+(a)llega funziona bene senza ``set paste``
+
+Potete generare le patch con ``git format-patch`` e usare Mutt per inviarle::
+
+ $ mutt -H 0001-some-bug-fix.patch
+
+Opzioni per la configurazione:
+
+Tutto dovrebbe funzionare già nella configurazione base.
+Tuttavia, è una buona idea quella di impostare ``send_charset``::
+
+ set send_charset="us-ascii:utf-8"
+
+Mutt è molto personalizzabile. Qui di seguito trovate la configurazione minima
+per iniziare ad usare Mutt per inviare patch usando Gmail::
+
+ # .muttrc
+ # ================ IMAP ====================
+ set imap_user = 'yourusername@gmail.com'
+ set imap_pass = 'yourpassword'
+ set spoolfile = imaps://imap.gmail.com/INBOX
+ set folder = imaps://imap.gmail.com/
+ set record="imaps://imap.gmail.com/[Gmail]/Sent Mail"
+ set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"
+ set mbox="imaps://imap.gmail.com/[Gmail]/All Mail"
+
+ # ================ SMTP ====================
+ set smtp_url = "smtp://username@smtp.gmail.com:587/"
+ set smtp_pass = $imap_pass
+ set ssl_force_tls = yes # Require encrypted connection
+
+ # ================ Composition ====================
+ set editor = `echo \$EDITOR`
+ set edit_headers = yes # See the headers when editing
+ set charset = UTF-8 # value of $LANG; also fallback for send_charset
+ # Sender, email address, and sign-off line must match
+ unset use_domain # because joe@localhost is just embarrassing
+ set realname = "YOUR NAME"
+ set from = "username@gmail.com"
+ set use_from = yes
+
+La documentazione di Mutt contiene molte più informazioni:
+
+ http://dev.mutt.org/trac/wiki/UseCases/Gmail
+
+ http://dev.mutt.org/doc/manual.html
+
+Pine (TUI)
+**********
+
+Pine aveva alcuni problemi con gli spazi vuoti, ma questi dovrebbero essere
+stati risolti.
+
+Se potete usate alpine (il successore di pine).
+
+Opzioni di configurazione:
+
+- Nelle versioni più recenti è necessario avere ``quell-flowed-text``
+- l'opzione ``no-strip-whitespace-before-send`` è necessaria
+
+Sylpheed (GUI)
+**************
+
+- funziona bene per aggiungere testo in linea (o usando allegati)
+- permette di utilizzare editor esterni
+- è lento su cartelle grandi
+- non farà l'autenticazione TSL SMTP su una connessione non SSL
+- ha un utile righello nella finestra di scrittura
+- la rubrica non comprende correttamente il nome da visualizzare e
+ l'indirizzo associato
+
+Thunderbird (GUI)
+*****************
+
+Thunderbird è un clone di Outlook a cui piace maciullare il testo, ma esistono
+modi per impedirglielo.
+
+- permettere l'uso di editor esterni:
+ La cosa più semplice da fare con Thunderbird e le patch è quello di usare
+ l'estensione "external editor" e di usare il vostro ``$EDITOR`` preferito per
+ leggere/includere patch nel vostro messaggio. Per farlo, scaricate ed
+ installate l'estensione e aggiungete un bottone per chiamarla rapidamente
+ usando :menuselection:`Visualizza-->Barra degli strumenti-->Personalizza...`;
+ una volta fatto potrete richiamarlo premendo sul bottone mentre siete nella
+ finestra :menuselection:`Scrivi`
+
+ Tenete presente che "external editor" richiede che il vostro editor non
+ faccia alcun fork, in altre parole, l'editor non deve ritornare prima di
+ essere stato chiuso. Potreste dover passare dei parametri aggiuntivi al
+ vostro editor oppure cambiargli la configurazione. Per esempio, usando
+ gvim dovrete aggiungere l'opzione -f ``/usr/bin/gvim -f`` (Se il binario
+ si trova in ``/usr/bin``) nell'apposito campo nell'interfaccia di
+ configurazione di :menuselection:`external editor`. Se usate altri editor
+ consultate il loro manuale per sapere come configurarli.
+
+Per rendere l'editor interno un po' più sensato, fate così:
+
+- Modificate le impostazioni di Thunderbird per far si che non usi
+ ``format=flowed``. Andate in :menuselection:`Modifica-->Preferenze-->Avanzate-->Editor di configurazione`
+ per invocare il registro delle impostazioni.
+
+- impostate ``mailnews.send_plaintext_flowed`` a ``false``
+
+- impostate ``mailnews.wraplength`` da ``72`` a ``0``
+
+- :menuselection:`Visualizza-->Corpo del messaggio come-->Testo semplice`
+
+- :menuselection:`Visualizza-->Codifica del testo-->Unicode`
+
+
+TkRat (GUI)
+***********
+
+Funziona. Usare "Inserisci file..." o un editor esterno.
+
+Gmail (Web GUI)
+***************
+
+Non funziona per inviare le patch.
+
+Il programma web Gmail converte automaticamente i tab in spazi.
+
+Allo stesso tempo aggiunge andata a capo ogni 78 caratteri. Comunque
+il problema della conversione fra spazi e tab può essere risolto usando
+un editor esterno.
+
+Un altro problema è che Gmail usa la codifica base64 per tutti quei messaggi
+che contengono caratteri non ASCII. Questo include cose tipo i nomi europei.
diff --git a/Documentation/translations/it_IT/process/management-style.rst b/Documentation/translations/it_IT/process/management-style.rst
index 07e68bfb8402..03794ebf7bd3 100644
--- a/Documentation/translations/it_IT/process/management-style.rst
+++ b/Documentation/translations/it_IT/process/management-style.rst
@@ -1,12 +1,294 @@
.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/management-style.rst <managementstyle>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
.. _it_managementstyle:
-Tipo di gestione del kernel Linux
-=================================
+Il modello di gestione del kernel Linux
+=======================================
-.. warning::
+Questo breve documento descrive il modello di gestione del kernel Linux.
+Per certi versi, esso rispecchia il documento
+:ref:`translations/it_IT/process/coding-style.rst <it_codingstyle>`,
+ed è principalmente scritto per evitare di rispondere [#f1]_ in continuazione
+alle stesse identiche (o quasi) domande.
- TODO ancora da tradurre
+Il modello di gestione è qualcosa di molto personale e molto più difficile da
+qualificare rispetto a delle semplici regole di codifica, quindi questo
+documento potrebbe avere più o meno a che fare con la realtà. È cominciato
+come un gioco, ma ciò non significa che non possa essere vero.
+Lo dovrete decidere voi stessi.
+
+In ogni caso, quando si parla del "dirigente del kernel", ci si riferisce
+sempre alla persona che dirige tecnicamente, e non a coloro che
+tradizionalmente hanno un ruolo direttivo all'interno delle aziende. Se vi
+occupate di convalidare acquisti o avete una qualche idea sul budget del vostro
+gruppo, probabilmente non siete un dirigente del kernel. Quindi i suggerimenti
+qui indicati potrebbero fare al caso vostro, oppure no.
+
+Prima di tutto, suggerirei di acquistare "Le sette regole per avere successo",
+e di non leggerlo. Bruciatelo, è un grande gesto simbolico.
+
+.. [#f1] Questo documento non fa molto per risponde alla domanda, ma rende
+ così dannatamente ovvio a chi la pone che non abbiamo la minima idea
+ di come rispondere.
+
+Comunque, partiamo:
+
+.. _it_decisions:
+
+1) Le decisioni
+---------------
+
+Tutti pensano che i dirigenti decidano, e che questo prendere decisioni
+sia importante. Più grande e dolorosa è la decisione, più importante deve
+essere il dirigente che la prende. Questo è molto profondo ed ovvio, ma non è
+del tutto vero.
+
+Il gioco consiste nell'"evitare" di dover prendere decisioni. In particolare
+se qualcuno vi chiede di "Decidere" tra (a) o (b), e vi dice che ha
+davvero bisogno di voi per questo, come dirigenti siete nei guai.
+Le persone che gestite devono conoscere i dettagli più di quanto li conosciate
+voi, quindi se vengono da voi per una decisione tecnica, siete fottuti.
+Non sarete chiaramente competente per prendere quella decisione per loro.
+
+(Corollario: se le persone che gestite non conoscono i dettagli meglio di voi,
+anche in questo caso sarete fregati, tuttavia per altre ragioni. Ossia state
+facendo il lavoro sbagliato, e che invece dovrebbero essere "loro" a gestirvi)
+
+Quindi il gioco si chiama "evitare" decisioni, almeno le più grandi e
+difficili. Prendere decisioni piccoli e senza conseguenze va bene, e vi fa
+sembrare competenti in quello che state facendo, quindi quello che un dirigente
+del kernel ha bisogno di fare è trasformare le decisioni grandi e difficili
+in minuzie delle quali nessuno importa.
+
+Ciò aiuta a capire che la differenza chiave tra una grande decisione ed una
+piccola sta nella possibilità di modificare tale decisione in seguito.
+Qualsiasi decisione importante può essere ridotta in decisioni meno importanti,
+ma dovete assicurarvi che possano essere reversibili in caso di errori
+(presenti o futuri). Improvvisamente, dovrete essere doppiamente dirigenti
+per **due** decisioni non sequenziali - quella sbagliata **e** quella giusta.
+
+E le persone vedranno tutto ciò come prova di vera capacità di comando
+(*cough* cavolata *cough*)
+
+Così la chiave per evitare le decisioni difficili diviene l'evitare
+di fare cose che non possono essere disfatte. Non infilatevi in un angolo
+dal quale non potrete sfuggire. Un topo messo all'angolo può rivelarsi
+pericoloso - un dirigente messo all'angolo è solo pietoso.
+
+**In ogni caso** dato che nessuno è stupido al punto da lasciare veramente ad
+un dirigente del kernel un enorme responsabilità, solitamente è facile fare
+marcia indietro. Annullare una decisione è molto facile: semplicemente dite a
+tutti che siete stati degli scemi incompetenti, dite che siete dispiaciuti, ed
+annullate tutto l'inutile lavoro sul quale gli altri hanno lavorato nell'ultimo
+anno. Improvvisamente la decisione che avevate preso un anno fa non era poi
+così grossa, dato che può essere facilmente annullata.
+
+È emerso che alcune persone hanno dei problemi con questo tipo di approccio,
+questo per due ragioni:
+
+ - ammettere di essere degli idioti è più difficile di quanto sembri. A tutti
+ noi piace mantenere le apparenze, ed uscire allo scoperto in pubblico per
+ ammettere che ci si è sbagliati è qualcosa di davvero impegnativo.
+ - avere qualcuno che ti dice che ciò su cui hai lavorato nell'ultimo anno
+ non era del tutto valido, può rivelarsi difficile anche per un povero ed
+ umile ingegnere, e mentre il **lavoro** vero era abbastanza facile da
+ cancellare, dall'altro canto potreste aver irrimediabilmente perso la
+ fiducia di quell'ingegnere. E ricordate che l'"irrevocabile" era quello
+ che avevamo cercato di evitare fin dall'inizio, e la vostra decisione
+ ha finito per esserlo.
+
+Fortunatamente, entrambe queste ragioni posso essere mitigate semplicemente
+ammettendo fin dal principio che non avete una cavolo di idea, dicendo
+agli altri in anticipo che la vostra decisione è puramente ipotetica, e che
+potrebbe essere sbagliata. Dovreste sempre riservarvi il diritto di cambiare
+la vostra opinione, e rendere gli altri ben **consapevoli** di ciò.
+Ed è molto più facile ammettere di essere stupidi quando non avete **ancora**
+fatto quella cosa stupida.
+
+Poi, quando è realmente emersa la vostra stupidità, le persone semplicemente
+roteeranno gli occhi e diranno "Uffa, no, ancora".
+
+Questa ammissione preventiva di incompetenza potrebbe anche portare le persone
+che stanno facendo il vero lavoro, a pensarci due volte. Dopo tutto, se
+**loro** non sono certi se sia una buona idea, voi, sicuro come l'inferno,
+non dovreste incoraggiarli promettendogli che ciò su cui stanno lavorando
+verrà incluso. Fate si che ci pensino due volte prima che si imbarchino in un
+grosso lavoro.
+
+Ricordate: loro devono sapere più cose sui dettagli rispetto a voi, e
+solitamente pensano di avere già la risposta a tutto. La miglior cosa che
+potete fare in qualità di dirigente è di non instillare troppa fiducia, ma
+invece fornire una salutare dose di pensiero critico su quanto stanno facendo.
+
+Comunque, un altro modo di evitare una decisione è quello di lamentarsi
+malinconicamente dicendo : "non possiamo farli entrambi e basta?" e con uno
+sguardo pietoso. Fidatevi, funziona. Se non è chiaro quale sia il miglior
+approccio, lo scopriranno. La risposta potrebbe essere data dal fatto che
+entrambe i gruppi di lavoro diventano frustati al punto di rinunciarvi.
+
+Questo può suonare come un fallimento, ma di solito questo è un segno che
+c'era qualcosa che non andava in entrambe i progetti, e il motivo per
+il quale le persone coinvolte non abbiano potuto decidere era che entrambe
+sbagliavano. Voi ne uscirete freschi come una rosa, e avrete evitato un'altra
+decisione con la quale avreste potuto fregarvi.
+
+
+2) Le persone
+-------------
+
+Molte persone sono idiote, ed essere un dirigente significa che dovrete
+scendere a patti con questo, e molto più importate, che **loro** devono avere
+a che fare con **voi**.
+
+Ne emerge che mentre è facile annullare degli errori tecnici, non è invece
+così facile annullare disordini della personalità. Dovrete semplicemente
+convivere con i loro, ed i vostri, problemi.
+
+Comunque, al fine di preparavi in qualità di dirigenti del kernel, è meglio
+ricordare di non abbattere alcun ponte, bombardare alcun paesano innocente,
+o escludere troppi sviluppatori kernel. Ne emerge che escludere le persone
+è piuttosto facile, mentre includerle nuovamente è difficile. Così
+"l'esclusione" immediatamente cade sotto il titolo di "non reversibile", e
+diviene un no-no secondo la sezione :ref:`Le decisioni`.
+
+Esistono alcune semplici regole qui:
+
+ (1) non chiamate le persone teste di c*** (al meno, non in pubblico)
+ (2) imparate a scusarvi quando dimenticate la regola (1)
+
+Il problema del punto numero #1 è che è molto facile da rispettare, dato che
+è possibile dire "sei una testa di c***" in milioni di modi differenti [#f2]_,
+a volte senza nemmeno pensarci, e praticamente sempre con calda convinzione
+che siete nel giusto.
+
+E più convinti sarete che avete ragione (e diciamolo, potete chiamare
+praticamente **tutti** testa di c**, e spesso **sarete** nel giusto), più
+difficile sarà scusarvi successivamente.
+
+Per risolvere questo problema, avete due possibilità:
+
+ - diventare davvero bravi nello scusarsi
+ - essere amabili così che nessuno finirà col sentirsi preso di mira. Siate
+ creativi abbastanza, e potrebbero esserne divertiti.
+
+L'opzione dell'essere immancabilmente educati non esiste proprio. Nessuno
+si fiderà di qualcuno che chiaramente sta nascondendo il suo vero carattere.
+
+.. [#f2] Paul Simon cantava: "50 modi per lasciare il vostro amante", perché,
+ molto francamente, "Un milione di modi per dire ad uno sviluppatore
+ Testa di c***" non avrebbe funzionato. Ma sono sicuro che ci abbia
+ pensato.
+
+
+3) Le persone II - quelle buone
+-------------------------------
+
+Mentre emerge che la maggior parte delle persone sono idiote, il corollario
+a questo è la tristezza che anche voi siate tra queste, e che mentre possiamo
+tutti crogiolarci nella sicurezza di essere migliori della media delle persone
+(diciamocelo, nessuno crede di essere nelle media o sotto di essa), dovremmo
+anche ammettere che non siamo il "coltello più affilato" del circondario, e che
+ci saranno altre persone che sono meno stupide di quanto siete voi.
+
+Molti reagiscono male davanti alle persone intelligenti. Altri le usano a
+proprio vantaggio.
+
+Assicuratevi che voi, in qualità di manutentori del kernel, siate nel secondo
+gruppo. Inchinatevi dinanzi a loro, perché saranno le persone che vi renderanno
+il lavoro più facile. In particolare, prenderanno le decisioni per voi, che è
+la oggetto di questo gioco.
+
+Quindi quando trovate qualcuno più sveglio di voi, prendetevela comoda.
+Le vostre responsabilità dirigenziali si ridurranno in gran parte nel dire
+"Sembra una buona idea - Vai", oppure "Sembra buono, ma invece circa questo e
+quello?". La seconda versione in particolare è una gran modo per imparare
+qualcosa di nuovo circa "questo e quello" o di sembrare **extra** dirigenziali
+sottolineando qualcosa alla quale i più svegli non avevano pensato. In
+entrambe i casi, vincete.
+
+Una cosa alla quale dovete fare attenzione è che l'essere grandi in qualcosa
+non si traduce automaticamente nell'essere grandi anche in altre cose. Quindi
+dovreste dare una spintarella alle persone in una specifica direzione, ma
+diciamocelo, potrebbero essere bravi in ciò che fanno e far schifo in tutto
+il resto. La buona notizia è che le persone tendono a gravitare attorno a ciò
+in cui sono bravi, quindi non state facendo nulla di irreversibile quando li
+spingete verso una certa direzione, solo non spingete troppo.
+
+
+4) Addossare le colpe
+---------------------
+
+Le cose andranno male, e le persone vogliono qualcuno da incolpare. Sarete voi.
+
+Non è poi così difficile accettare la colpa, specialmente se le persone
+riescono a capire che non era **tutta** colpa vostra. Il che ci porta
+sulla miglior strada per assumersi la colpa: fatelo per qualcun'altro.
+Vi sentirete bene nel assumervi la responsabilità, e loro si sentiranno
+bene nel non essere incolpati, e coloro che hanno perso i loro 36GB di porno
+a causa della vostra incompetenza ammetteranno a malincuore che alla fine
+non avete cercato di fare il furbetto.
+
+Successivamente fate in modo che gli sviluppatori che in realtà hanno fallito
+(se riuscite a trovarli) sappiano **in privato** che sono "fottuti".
+Questo non per fargli sapere che la prossima volta possono evitarselo ma per
+fargli capire che sono in debito. E, forse cosa più importante, sono loro che
+devono sistemare la cosa. Perché, ammettiamolo, è sicuro non sarete voi a
+farlo.
+
+Assumersi la colpa è anche ciò che vi rendere dirigenti in prima battuta.
+È parte di ciò che spinge gli altri a fidarsi di voi, e vi garantisce
+la gloria potenziale, perché siete gli unici a dire "Ho fatto una cavolata".
+E se avete seguito le regole precedenti, sarete decisamente bravi nel dirlo.
+
+
+5) Le cose da evitare
+---------------------
+
+Esiste una cosa che le persone odiano più che essere chiamate "teste di c****",
+ed è essere chiamate "teste di c****" con fare da bigotto. Se per il primo
+caso potrete comunque scusarvi, per il secondo non ve ne verrà data nemmeno
+l'opportunità. Probabilmente smetteranno di ascoltarvi anche se tutto sommato
+state svolgendo un buon lavoro.
+
+Tutti crediamo di essere migliori degli altri, il che significa che quando
+qualcuno inizia a darsi delle arie, ci da **davvero** fastidio. Potreste anche
+essere moralmente ed intellettualmente superiore a tutti quelli attorno a voi,
+ma non cercate di renderlo ovvio per gli altri a meno che non **vogliate**
+veramente far arrabbiare qualcuno [#f3]_.
+
+Allo stesso modo evitate di essere troppo gentili e pacati. Le buone maniere
+facilmente finiscono per strabordare e nascondere i problemi, e come si usa
+dire, "su internet nessuno può sentire la vostra pacatezza". Usate argomenti
+diretti per farvi capire, non potete sperare che la gente capisca in altro
+modo.
+
+Un po' di umorismo può aiutare a smorzare sia la franchezza che la moralità.
+Andare oltre i limiti al punto d'essere ridicolo può portare dei punti a casa
+senza renderlo spiacevole per i riceventi, i quali penseranno che stavate
+facendo gli scemi. Può anche aiutare a lasciare andare quei blocchi mentali
+che abbiamo nei confronti delle critiche.
+
+.. [#f3] Suggerimento: i forum di discussione su internet, che non sono
+ collegati col vostro lavoro, sono ottimi modi per sfogare la frustrazione
+ verso altre persone. Di tanto in tanto scrivete messaggi offensivi col ghigno
+ in faccia per infiammare qualche discussione: vi sentirete purificati. Solo
+ cercate di non cagare troppo vicino a casa.
+
+6) Perché io?
+-------------
+
+Dato che la vostra responsabilità principale è quella di prendervi le colpe
+d'altri, e rendere dolorosamente ovvio a tutti che siete degli incompetenti,
+la domanda naturale che ne segue sarà : perché dovrei fare tutto ciò?
+
+Innanzitutto, potreste diventare o no popolari al punto da avere la fila di
+ragazzine (o ragazzini, evitiamo pregiudizi o sessismo) che gridano e bussano
+alla porta del vostro camerino, ma comunque **proverete** un immenso senso di
+realizzazione personale dall'essere "in carica". Dimenticate il fatto che voi
+state discutendo con tutti e che cercate di inseguirli il più velocemente che
+potete. Tutti continueranno a pensare che voi siete la persona in carica.
+
+È un bel lavoro se riuscite ad adattarlo a voi.
--
2.21.0
^ permalink raw reply related
* [PATCH v7] Documentation/checkpatch: Prefer stracpy/strscpy over strcpy/strlcpy/strncpy.
From: NitinGote @ 2019-07-28 16:06 UTC (permalink / raw)
To: joe, keescook; +Cc: corbet, akpm, apw, linux-doc, kernel-hardening, Nitin Gote
From: Nitin Gote <nitin.r.gote@intel.com>
Added check in checkpatch.pl to deprecate strcpy(), strlcpy() and
strncpy() in favor of stracpy() or strscpy().
Updated Documentation/process/deprecated.rst for stracpy() and strscpy().
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
---
Change log:
v6->v7
- Favored both stracpy() or strscpy(), as stracpy() preferred when the
destination is char array (rather than string pointer).
v5->v6
- Used stracpy() instead of strscpy().
v4->v5
- Change the subject line as per review comment.
- v5 is Reviewed-by: Kees Cook <keescook@chromium.org>
v3->v4
- Removed "c:func:" from deprecated.rst as per review comment.
v2->v3
- Avoided use of $check in implementation.
- Incorporated trivial comments.
v1->v2
- For string related apis, created different %deprecated_string_api
and these will get emitted at CHECK Level using command line option
-f/--file to avoid bad patched from novice script users.
Documentation/process/deprecated.rst | 10 +++++-----
scripts/checkpatch.pl | 24 ++++++++++++++++++++++++
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index 49e0f64a3427..b4c82589d301 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -84,7 +84,7 @@ buffer. This could result in linear overflows beyond the
end of the buffer, leading to all kinds of misbehaviors. While
`CONFIG_FORTIFY_SOURCE=y` and various compiler flags help reduce the
risk of using this function, there is no good reason to add new uses of
-this function. The safe replacement is :c:func:`strscpy`.
+this function. The safe replacement is stracpy() or strscpy().
strncpy() on NUL-terminated strings
-----------------------------------
@@ -93,9 +93,9 @@ will be NUL terminated. This can lead to various linear read overflows
and other misbehavior due to the missing termination. It also NUL-pads the
destination buffer if the source contents are shorter than the destination
buffer size, which may be a needless performance penalty for callers using
-only NUL-terminated strings. The safe replacement is :c:func:`strscpy`.
-(Users of :c:func:`strscpy` still needing NUL-padding will need an
-explicit :c:func:`memset` added.)
+only NUL-terminated strings. In this case, the safe replacement is
+stracpy() or strscpy(). If, however, the destination buffer still needs
+NUL-padding, the safe replacement is stracpy_pad().
If a caller is using non-NUL-terminated strings, :c:func:`strncpy()` can
still be used, but destinations should be marked with the `__nonstring
@@ -107,7 +107,7 @@ strlcpy()
:c:func:`strlcpy` reads the entire source buffer first, possibly exceeding
the given limit of bytes to copy. This is inefficient and can lead to
linear read overflows if a source string is not NUL-terminated. The
-safe replacement is :c:func:`strscpy`.
+safe replacement is stracpy() or strscpy().
Variable Length Arrays (VLAs)
-----------------------------
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 342c7c781ba5..0e14a1ae6502 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -605,6 +605,20 @@ foreach my $entry (keys %deprecated_apis) {
}
$deprecated_apis_search = "(?:${deprecated_apis_search})";
+our %deprecated_string_apis = (
+ "strcpy" => "stracpy or strscpy",
+ "strlcpy" => "stracpy or strscpy",
+ "strncpy" => "stracpy or strscpy - for non-NUL-terminated uses, strncpy dest should be __nonstring",
+);
+
+#Create a search pattern for all these strings apis to speed up a loop below
+our $deprecated_string_apis_search = "";
+foreach my $entry (keys %deprecated_string_apis) {
+ $deprecated_string_apis_search .= '|' if ($deprecated_string_apis_search ne "");
+ $deprecated_string_apis_search .= $entry;
+}
+$deprecated_string_apis_search = "(?:${deprecated_string_apis_search})";
+
our $mode_perms_world_writable = qr{
S_IWUGO |
S_IWOTH |
@@ -6446,6 +6460,16 @@ sub process {
"Deprecated use of '$deprecated_api', prefer '$new_api' instead\n" . $herecurr);
}
+# check for string deprecated apis
+ if ($line =~ /\b($deprecated_string_apis_search)\b\s*\(/) {
+ my $deprecated_string_api = $1;
+ my $new_api = $deprecated_string_apis{$deprecated_string_api};
+ my $msg_level = \&WARN;
+ $msg_level = \&CHK if ($file);
+ &{$msg_level}("DEPRECATED_API",
+ "Deprecated use of '$deprecated_string_api', prefer '$new_api' instead\n" . $herecurr);
+ }
+
# check for various structs that are normally const (ops, kgdb, device_tree)
# and avoid what seem like struct definitions 'struct foo {'
if ($line !~ /\bconst\b/ &&
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 18/20] docs: ABI: don't escape ReST-incompatible chars from obsolete and removed
From: Linus Walleij @ 2019-07-28 22:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg KH, Bartosz Golaszewski, Jonathan Corbet,
open list:GPIO SUBSYSTEM, Linux Doc Mailing List
In-Reply-To: <07b6de638cb80767dd3ea2fdec8b19ee3ceb60a7.1563360659.git.mchehab+samsung@kernel.org>
On Wed, Jul 17, 2019 at 1:05 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> With just a single fix, the contents there can be parsed properly
> without the need to escape any ReST incompatible stuff.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This seems to depend on other stuff so:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] docs/pinctrl: fix compile errors in example code
From: Linus Walleij @ 2019-07-28 22:20 UTC (permalink / raw)
To: Luca Ceresoli
Cc: open list:GPIO SUBSYSTEM, Jonathan Corbet, Linux Doc Mailing List,
linux-kernel@vger.kernel.org
In-Reply-To: <20190705143043.1929-1-luca@lucaceresoli.net>
On Fri, Jul 5, 2019 at 4:30 PM Luca Ceresoli <luca@lucaceresoli.net> wrote:
> The code in the example does not build for a few trivial errors: type
> mismatch in callback, missing semicolon. Fix them to help newcomers using
> the example as a starting point.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] Documentation: gpio: fix function links in the HTML docs
From: Linus Walleij @ 2019-07-28 23:05 UTC (permalink / raw)
To: Jeremy Cline
Cc: Bartosz Golaszewski, Jonathan Corbet, open list:GPIO SUBSYSTEM,
Linux Doc Mailing List, linux-kernel@vger.kernel.org
In-Reply-To: <20190708211123.16495-1-jcline@redhat.com>
On Mon, Jul 8, 2019 at 11:11 PM Jeremy Cline <jcline@redhat.com> wrote:
> The shorthand [_data] and [devm_] cause the HTML documentation to not
> link to the function documentation properly. This expands the references
> to the complete function names with the exception of
> devm_gpiochip_remove() which was dropped by commit 48207d7595d2 ("gpio:
> drop devm_gpiochip_remove()").
>
> Signed-off-by: Jeremy Cline <jcline@redhat.com>
This does not apply to v5.3-rc1 can you rebase and resend?
Thanks!
Linus Walleij
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Jaegeuk Kim @ 2019-07-29 6:27 UTC (permalink / raw)
To: Chao Yu
Cc: Daniel Rosenberg, Chao Yu, Jonathan Corbet, linux-f2fs-devel,
linux-doc, linux-api, linux-kernel, linux-fsdevel, kernel-team
In-Reply-To: <9362e4ed-2be8-39f5-b4d9-9c86e37ab993@kernel.org>
On 07/28, Chao Yu wrote:
> On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
> > /* Flags that are appropriate for regular files (all but dir-specific ones). */
> > #define F2FS_REG_FLMASK (~(F2FS_DIRSYNC_FL | F2FS_PROJINHERIT_FL))
>
> We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.
Applied.
>
> > @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
> > return -EPERM;
> >
> > oldflags = fi->i_flags;
> > + if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
> > + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
> > + return -EOPNOTSUPP;
> > +
> > + if (!S_ISDIR(inode->i_mode))
> > + return -ENOTDIR;
> >
> > + if (!f2fs_empty_dir(inode))
> > + return -ENOTEMPTY;
> > + }
Modified like this:
@@ -1665,6 +1665,13 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
if (IS_NOQUOTA(inode))
return -EPERM;
+ if ((iflags ^ fi->i_flags) & F2FS_CASEFOLD_FL) {
+ if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
+ return -EOPNOTSUPP;
+ if (!f2fs_empty_dir(inode))
+ return -ENOTEMPTY;
+ }
+
Note that, directory is checked by above change.
I've uploaded in f2fs.git, so could you check it out and test a bit?
Thanks,
>
> I applied the patches based on last Jaegeuk's dev branch, it seems we needs to
> adjust above code a bit. Otherwise it looks good to me.
>
> BTW, it looks the patchset works fine with generic/556 testcase.
>
> Thanks,
^ permalink raw reply
* Re: [RFC 3/7] tee: add private login method for kernel clients
From: Jens Wiklander @ 2019-07-29 7:08 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jonathan Corbet,
dhowells, jejb, Jarkko Sakkinen, Mimi Zohar, jmorris, serge,
Ard Biesheuvel, Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYPHVXbsOjzGVT1WWziMRKmWns=3YkD6_j+C1OJxTUbDmw@mail.gmail.com>
Hi Sumit,
On Tue, Jul 9, 2019 at 11:36 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Tue, 9 Jul 2019 at 12:33, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> >
> > On Tue, Jul 09, 2019 at 11:26:19AM +0530, Sumit Garg wrote:
> > > Thanks Jens for your comments.
> > >
> > > On Mon, 8 Jul 2019 at 21:09, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > > >
> > > > Hi Sumit,
> > > >
> > > > On Thu, Jun 13, 2019 at 04:00:29PM +0530, Sumit Garg wrote:
> > > > > There are use-cases where user-space shouldn't be allowed to communicate
> > > > > directly with a TEE device which is dedicated to provide a specific
> > > > > service for a kernel client. So add a private login method for kernel
> > > > > clients and disallow user-space to open-session using this login method.
> > > > >
> > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > ---
> > > > > drivers/tee/tee_core.c | 6 ++++++
> > > > > include/uapi/linux/tee.h | 2 ++
> > > > > 2 files changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > > > index 0f16d9f..4581bd1 100644
> > > > > --- a/drivers/tee/tee_core.c
> > > > > +++ b/drivers/tee/tee_core.c
> > > > > @@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct tee_context *ctx,
> > > > > goto out;
> > > > > }
> > > > >
> > > > > + if (arg.clnt_login == TEE_IOCTL_LOGIN_REE_KERNEL) {
> > > > TEE_IOCTL_LOGIN_REE_KERNEL is defined as 0x80000000 which is in the
> > > > range specified and implementation defined by the GP spec. I wonder if
> > > > we shouldn't filter the entire implementation defined range instead of
> > > > just this value.
> > >
> > > Agree. Will rather check for entire implementation defined range:
> > > 0x80000000 - 0xFFFFFFFF.
> > >
>
> I had a second thought on this. It would be more restrictive for
> user-space TEE client library which may need to use implementation
> defined login method. So either we could define specific ranges for
> kernel and user-space or we can start with single login method
> reserved for kernel.
I think we should reserve a range for kernel internal use. Only
reserving a single single login for kernel could force us to restrict
the API once more later, better to take a chunk now and be done with
it. Half of 0x80000000 - 0xFFFFFFFF is probably more than enough too
to leave a range for user space too.
>
> > > >
> > > > > + pr_err("login method not allowed for user-space client\n");
> > > > pr_debug(), if it's needed at all.
> > > >
> > >
> > > Ok will use pr_debug() instead.
> > >
> > > > > + rc = -EPERM;
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
> > > > > if (rc)
> > > > > goto out;
> > > > > diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
> > > > > index 4b9eb06..f33c69c 100644
> > > > > --- a/include/uapi/linux/tee.h
> > > > > +++ b/include/uapi/linux/tee.h
> > > > > @@ -172,6 +172,8 @@ struct tee_ioctl_buf_data {
> > > > > #define TEE_IOCTL_LOGIN_APPLICATION 4
> > > > > #define TEE_IOCTL_LOGIN_USER_APPLICATION 5
> > > > > #define TEE_IOCTL_LOGIN_GROUP_APPLICATION 6
> > > > > +/* Private login method for REE kernel clients */
> > > > It's worth noting that this is filtered by the TEE framework, compared
> > > > to everything else which is treated opaquely.
> > > >
> > >
> > > IIUC, you are referring to login filter in optee_os. Change to prevent
> > > filter for this login method is part of this PR [1].
> > >
> > > [1] https://github.com/OP-TEE/optee_os/pull/3082
> >
> > No, I was referring to the changes in tee_ioctl_open_session() above.
> > It's relevant for user space to know since it will be prevented from
> > using that range of login identifiers.
>
> Ok, so you mean to extend the comment here for user-space to know that
> this login method/range is filtered by the TEE framework. Will do
> that.
>
> > This will restrict the user space
> > API, but I think the risk of breakage is minimal as OP-TEE is the only
> > in-tree driver registering in the TEE framework. I'm not aware of any
> > out-of-tree drivers registering.
>
> I am not sure if I follow you here. How do you expect this change to
> break out-of-tree TEE driver registration?
It's a change in common code that put restrictions on the API.
Thanks,
Jens
>
> -Sumit
>
> >
> > Thanks,
> > Jens
> >
> > >
> > > -Sumit
> > >
> > > > > +#define TEE_IOCTL_LOGIN_REE_KERNEL 0x80000000
> > > > >
> > > > > /**
> > > > > * struct tee_ioctl_param - parameter
> > > > > --
> > > > > 2.7.4
> > > > >
> > > >
> > > > Thanks,
> > > > Jens
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Chao Yu @ 2019-07-29 7:22 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu
Cc: Daniel Rosenberg, Jonathan Corbet, linux-f2fs-devel, linux-doc,
linux-api, linux-kernel, linux-fsdevel, kernel-team
In-Reply-To: <20190729062735.GA98839@jaegeuk-macbookpro.roam.corp.google.com>
On 2019/7/29 14:27, Jaegeuk Kim wrote:
> On 07/28, Chao Yu wrote:
>> On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
>>> /* Flags that are appropriate for regular files (all but dir-specific ones). */
>>> #define F2FS_REG_FLMASK (~(F2FS_DIRSYNC_FL | F2FS_PROJINHERIT_FL))
>>
>> We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.
>
> Applied.
>
>>
>>> @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
>>> return -EPERM;
>>>
>>> oldflags = fi->i_flags;
>>> + if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
>>> + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
>>> + return -EOPNOTSUPP;
>>> +
>>> + if (!S_ISDIR(inode->i_mode))
>>> + return -ENOTDIR;
>>>
>>> + if (!f2fs_empty_dir(inode))
>>> + return -ENOTEMPTY;
>>> + }
>
> Modified like this:
> @@ -1665,6 +1665,13 @@ static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
> if (IS_NOQUOTA(inode))
> return -EPERM;
>
> + if ((iflags ^ fi->i_flags) & F2FS_CASEFOLD_FL) {
> + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
> + return -EOPNOTSUPP;
> + if (!f2fs_empty_dir(inode))
> + return -ENOTEMPTY;
> + }
> +
>
> Note that, directory is checked by above change.
>
> I've uploaded in f2fs.git, so could you check it out and test a bit?
I've checked it out, it looks good to me now, and later I will test this new
version.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
>
> Thanks,
>
>>
>> I applied the patches based on last Jaegeuk's dev branch, it seems we needs to
>> adjust above code a bit. Otherwise it looks good to me.
>>
>> BTW, it looks the patchset works fine with generic/556 testcase.
>>
>> Thanks,
> .
>
^ permalink raw reply
* Re: [PATCH 00/43] Convert doc files to ReST
From: Geert Uytterhoeven @ 2019-07-29 9:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
Linux Kernel Mailing List, Jonathan Corbet, Linux-Renesas
In-Reply-To: <cover.1561723979.git.mchehab+samsung@kernel.org>
Hi Mauro,
On Fri, Jun 28, 2019 at 2:25 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> This patchset contains the patches that weren't merged yet from
> part 2 and 3 of the previous ReST conversion patchset.
>
> This is based aganst linux-next (next-20190627), so they may not
> apply cleanly at docs-next.
>
> It does contain file renames, but, except for a few exceptions, the files
> are kept where they are.
>
> The first patches on this series were agreed to be merged via subsystem's
> tree, but, as they didn't appear at -next, I'm recending as a gentile
> ping.
[...]
> .../arm/{SH-Mobile => sh-mobile}/.gitignore | 0
I guess that should have been "shmobile^H^H^H^H^H^H^H^Hrenesas",
for consistency with modern naming?
For whatever it's worth keeping empty subdirectories, of course,
containing just an obsolete .gitignore file...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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