Fine-tuning:
* s/Linus' tree/Linux mainline/, as mainline is the term used elsewhere
in the document.
* Provide a better example for the 'delayed backporting' case that uses
a fixed rather than a relative reference point, which makes it easier
to handle for the stable team.
Signed-off-by:
Document a new variant of the stable tag developers can use to make the
stable team's tools ignore a change[1].
That way developers can use 'Fixes:' tags without fearing the changes
might be backported in semi-automatic fashion. Such concerns are the
reason why some developers deliberately omit th
Explain the general concept once in the intro to keep things somewhat
shorter in the individual points.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Thorsten Leemhuis
---
Documentation/process/stable-kernel-rules.rst | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --
Remove the 'code-block:: none' labels and switch to the shorter '::' to
reduce noise.
Remove a unneeded level of indentation, as that reduces the chance that
readers have to scroll sideways in some of the code blocks.
No text changes. Rendered html output looks like before, except for the
differe
Document when to use of sta...@kernel.org instead of
sta...@vger.kernel.org, as the two are easily mixed up and their
difference not explained anywhere[1].
Link: https://lore.kernel.org/all/20240422231550.3cf5f...@sal.lan/ [1]
Signed-off-by: Thorsten Leemhuis
---
Documentation/process/stable-ker
After a recent discussion regarding "do we need a 'nobackport' tag" I
set out to create one change for stable-kernel-rules.rst. This is now
the last patch in the series, which links to that discussion with
all the details; the other stuff is fine-tuning that happened along the
way.
Ciao, Thorsten
On 23/04/2024 15:19, Andy Shevchenko wrote:
> The recommendation is based on the following rationale:
>
> - it makes the commit messages much cleaner and easy to read, especially
> on the screens of the mobile devices;
>
> - it reduces resources (memory, time, energy) to retrieve all these
>
On 23/04/2024 15:19, Andy Shevchenko wrote:
> Add a note that explains that Cc: email header is implied by other
> tags, such as Reviewed-by:. In this case an explicit Cc: is _not_
> needed.
>
> Signed-off-by: Andy Shevchenko
> ---
> Documentation/process/5.Posting.rst | 4 +++-
> Docu
On Mon, Apr 29, 2024 at 09:18:27AM +0200, Thorsten Leemhuis wrote:
> Fine-tuning:
>
> * s/Linus' tree/Linux mainline/, as mainline is the term used elsewhere
> in the document.
>
> * Provide a better example for the 'delayed backporting' case that uses
> a fixed rather than a relative referen
On Mon, Apr 29, 2024 at 09:18:28AM +0200, Thorsten Leemhuis wrote:
> Remove the 'code-block:: none' labels and switch to the shorter '::' to
> reduce noise.
>
> Remove a unneeded level of indentation, as that reduces the chance that
> readers have to scroll sideways in some of the code blocks.
>
On Mon, Apr 29, 2024 at 09:18:29AM +0200, Thorsten Leemhuis wrote:
> Document when to use of sta...@kernel.org instead of
> sta...@vger.kernel.org, as the two are easily mixed up and their
> difference not explained anywhere[1].
>
> Link: https://lore.kernel.org/all/20240422231550.3cf5f...@sal.lan
On Mon, Apr 29, 2024 at 09:18:30AM +0200, Thorsten Leemhuis wrote:
> Document a new variant of the stable tag developers can use to make the
> stable team's tools ignore a change[1].
>
> That way developers can use 'Fixes:' tags without fearing the changes
> might be backported in semi-automatic f
On 29.04.24 09:51, Greg Kroah-Hartman wrote:
> On Mon, Apr 29, 2024 at 09:18:29AM +0200, Thorsten Leemhuis wrote:
>> Document when to use of sta...@kernel.org instead of
>> sta...@vger.kernel.org, as the two are easily mixed up and their
>> difference not explained anywhere[1].
>>
>> Link: https://
On Mon, Apr 29, 2024 at 10:30:49AM +0200, Thorsten Leemhuis wrote:
> On 29.04.24 09:51, Greg Kroah-Hartman wrote:
> > On Mon, Apr 29, 2024 at 09:18:29AM +0200, Thorsten Leemhuis wrote:
> >> Document when to use of sta...@kernel.org instead of
> >> sta...@vger.kernel.org, as the two are easily mixed
On Mon, Apr 29, 2024 at 09:35:18AM +0200, Krzysztof Kozlowski wrote:
> On 23/04/2024 15:19, Andy Shevchenko wrote:
> > The recommendation is based on the following rationale:
> >
> > - it makes the commit messages much cleaner and easy to read, especially
> > on the screens of the mobile devices
Support of kprobes and kretprobes for riscv was introduced 3 years ago
by the following change:
commit c22b0bcb1dd0 ("riscv: Add kprobes supported")
Add riscv to the list of supported architectures.
Signed-off-by: Ivan Orlov
---
Documentation/trace/kprobes.rst | 1 +
1 file changed, 1 insertio
On Sun, 28 Apr 2024 22:49:09 +0800 Heng Qi wrote:
> >> +#if IS_ENABLED(CONFIG_DIMLIB)
> >> + if (dev->irq_moder) {
> > This may be NULL
>
>
> Do you mean dev may be null or dev->irq_moder may be null?
> The former has been excluded (see const struct ethtool_ops *ops
>
> = req_info->dev->eth
On Mon, 29 Apr 2024 10:47:41 -0700, Jakub Kicinski wrote:
> On Sun, 28 Apr 2024 22:49:09 +0800 Heng Qi wrote:
> > >> +nla_for_each_nested_type(nest,
> > >> ETHTOOL_A_PROFILE_IRQ_MODERATION, nests, rem) {
> > >> +ret = nla_parse_nested(moder,
> > >> +
On Tue, 30 Apr 2024 09:59:39 +0800 Heng Qi wrote:
> + if (moder[ETHTOOL_A_IRQ_MODERATION_USEC]) {
> + if (irq_moder->coal_flags & DIM_COALESCE_USEC)
> + new_profile[i].usec =
> + nla_get_u32(moder[ETHTOOL_A_IRQ_MODERATION_USEC]);
> + else
> + retu
On Mon, 29 Apr 2024 20:13:00 -0700, Jakub Kicinski wrote:
> On Tue, 30 Apr 2024 09:59:39 +0800 Heng Qi wrote:
> > + if (moder[ETHTOOL_A_IRQ_MODERATION_USEC]) {
> > + if (irq_moder->coal_flags & DIM_COALESCE_USEC)
> > + new_profile[i].usec =
> > + nla_get_u32(moder[ETH
On Mon, Apr 29, 2024 at 12:04:17PM -0500, John Groves wrote:
> * Introduce Documentation/filesystems/famfs.rst into the Documentation
> tree and filesystems index
> * Add famfs famfs.rst to the filesystems doc index
> * Add famfs' ioctl opcodes to ioctl-number.rst
> * Update MAINTAINERS FILE
>
21 matches
Mail list logo
