Hello.
On středa 1. září 2021 12:31:36 CEST Michal Hocko wrote:
> On Wed 01-09-21 11:21:49, Oleksandr Natalenko wrote:
> > There are various places where the K(x) macro is defined. This commit
> > gets rid of multiple definitions and provides a common one.
> >
> > This doesn't solve open-coding this macro in various other places. This
> > should be addressed by another subsequent commit.
>
> Why is this an improvement? You are adding a header file for a single
> macro which sounds like an overkill.
I agree a separate header file is an overkill for just one #define, hence
still looking for a suggestion on a better place for it.
> The overall net outcome is added
> lines of code.
Not always. There are some long statements like:
```
seq_printf(seq, ",size=%luk",
sbinfo->max_blocks << (PAGE_SHIFT - 10));
```
that are split into two lines. With the macro those take one line only:
```
seq_printf(seq, ",size=%luk", K(sbinfo->max_blocks));
```
As of now (counting unposted open-coding replacements) the grand total is:
```
31 files changed, 104 insertions(+), 90 deletions(-)
```
which is not that horrible.
> It is not like K() or any of its variant is adding a
> maintenance burden due to code duplication. So why do we want to change
> the existing state?
For me it's about readability. Compare, for instance:
```
seq_put_decimal_ull_width(m, str, (val) << (PAGE_SHIFT-10), 8)
```
and
```
seq_put_decimal_ull_width(m, str, K(val), 8)
```
It's a small yet visible difference.
Thanks.
--
Oleksandr Natalenko (post-factum)
