From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 15:12:19 +0100 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
Boqun Feng <boqun.feng@gmail.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org,
openrisc@lists.librecores.org, loongarch@lists.linux.dev,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 15:12:19 +0100 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
Boqun Feng <boqun.feng@gmail.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org,
openrisc@lists.librecores.org, loongarch@lists.linux.dev,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [Intel-gfx] [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 15:12:19 +0100 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 15:12:19 +0100 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 15:12:19 +0100 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 15:12:19 +0100 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg
Date: Thu, 22 Dec 2022 14:12:19 +0000 [thread overview]
Message-ID: <CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com> (raw)
In-Reply-To: <20221222114635.1251934-1-andrzej.hajda@intel.com>
Hi Andrzej,
Thanks for your series!
On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
> I am not sure who is good person to review/ack such patches,
> so I've used my intuition to construct to/cc lists, sorry for mistakes.
> This is the 2nd approach of the same idea, with comments addressed[0].
>
> The helper is tiny and there are advices we can leave without it, so
> I want to present few arguments why it would be good to have it:
>
> 1. Code readability/simplification/number of lines:
>
> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> - previous_min_rate = evport->qos.min_rate;
> - evport->qos.min_rate = min_rate;
> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
Upon closer look, shouldn't that be
previous_min_rate = __xchg(&evport->qos.min_rate, min_rate);
?
> For sure the code is more compact, and IMHO more readable.
>
> 2. Presence of similar helpers in other somehow related languages/libs:
>
> a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> helper (__xchg(&x, 0)), which is the same as private helper in
> i915 - fetch_and_zero, see latest patch.
> b) C++ [2]: 'exchange' from utility header.
>
> If the idea is OK there are still 2 qestions to answer:
>
> 1. Name of the helper, __xchg follows kernel conventions,
> but for me Rust names are also OK.
Before I realized the missing "&", I wondered how this is different
from swap(), so naming is important.
https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139
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
next prev parent reply other threads:[~2022-12-22 14:12 UTC|newest]
Thread overview: 306+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 11:46 [PATCH 00/19] Introduce __xchg, non-atomic xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 01/19] arch/alpha: rename internal name __xchg to __arch_xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 02/19] arch/arc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` [Intel-gfx] " Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 11:33 ` [PATCH v2] arch: rename all internal names " Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` [Intel-gfx] " Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` [Intel-gfx] " kernel test robot
2022-12-30 14:15 ` [PATCH v3] " Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` [Intel-gfx] " Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` [Intel-gfx] " Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-05 9:54 ` [PATCH v4] " Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` [Intel-gfx] " Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` [Intel-gfx] " Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-02 8:30 ` [PATCH v2] " Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` [Intel-gfx] " Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2022-12-22 11:46 ` [PATCH 03/19] arch/arm: rename internal name " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 04/19] arch/arm64: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 05/19] arch/hexagon: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 06/19] arch/ia64: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 07/19] arch/loongarch: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 08/19] arch/m68k: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 09/19] arch/mips: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 10/19] arch/openrisc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 11/19] arch/parisc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 12/19] arch/powerpc: correct logged function names in xchg helpers Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` [Intel-gfx] " Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` [Intel-gfx] " Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2022-12-22 11:46 ` [PATCH 14/19] arch/s390: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 15/19] arch/sh: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 16/19] arch/sparc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 17/19] arch/xtensa: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 18/19] linux/include: add non-atomic version of xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` [Intel-gfx] " Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 11:46 ` [PATCH 19/19] drm/i915/gt: use __xchg instead of internal helper Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 14:12 ` Geert Uytterhoeven [this message]
2022-12-22 14:12 ` [PATCH 00/19] Introduce __xchg, non-atomic xchg Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` [Intel-gfx] " Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` [Intel-gfx] " Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` [Intel-gfx] " Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` [Intel-gfx] " Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` [Intel-gfx] " Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-10 10:53 ` [RFC DO NOT MERGE] treewide: use __xchg in most obvious places Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` [Intel-gfx] " Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` [Intel-gfx] " Andy Shevchenko
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` [Intel-gfx] " Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 11:15 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork
2022-12-22 18:25 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce __xchg, non-atomic xchg Patchwork
2022-12-22 18:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-23 0:40 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-12-29 12:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce __xchg, non-atomic xchg (rev2) Patchwork
2022-12-29 12:23 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-12-30 14:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce __xchg, non-atomic xchg (rev3) Patchwork
2022-12-30 14:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-30 17:13 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdUE-a6SffG1PH=WfrMx-CNLB9EfUr4qmL_USBP31YGoNg@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andrzej.hajda@intel.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=openrisc@lists.librecores.org \
--cc=peterz@infradead.org \
--cc=rodrigo.vivi@intel.com \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.