lkml.org 
[lkml]   [2021]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 1/1] mm: provide one common K(x) macro
Date
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)


\
 
 \ /
  Last update: 2021-09-01 12:51    [W:0.051 / U:0.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site