[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHHnhej-jxkSBG5im+QXh5GZfp1KsO40EV=PPDxuGbco8Q@mail.gmail.com>
Date: Sat, 20 Sep 2025 07:47:46 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Russell Haley <yumpusamongus@...il.com>
Cc: brauner@...nel.org, viro@...iv.linux.org.uk, jack@...e.cz,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
josef@...icpanda.com, kernel-team@...com, amir73il@...il.com,
linux-btrfs@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, ceph-devel@...r.kernel.org,
linux-unionfs@...r.kernel.org
Subject: Re: [PATCH v5 0/4] hide ->i_state behind accessors
On Sat, Sep 20, 2025 at 6:31 AM Russell Haley <yumpusamongus@...il.com> wrote:
>
> On 9/19/25 10:49 AM, Mateusz Guzik wrote:
> > This is generated against:
> > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs-6.18.inode.refcount.preliminaries
> >
> > First commit message quoted verbatim with rationable + API:
> >
> > [quote]
> > Open-coded accesses prevent asserting they are done correctly. One
> > obvious aspect is locking, but significantly more can checked. For
> > example it can be detected when the code is clearing flags which are
> > already missing, or is setting flags when it is illegal (e.g., I_FREEING
> > when ->i_count > 0).
> >
> > Given the late stage of the release cycle this patchset only aims to
> > hide access, it does not provide any of the checks.
> >
> > Consumers can be trivially converted. Suppose flags I_A and I_B are to
> > be handled, then:
> >
> > state = inode->i_state => state = inode_state_read(inode)
> > inode->i_state |= (I_A | I_B) => inode_state_add(inode, I_A | I_B)
> > inode->i_state &= ~(I_A | I_B) => inode_state_del(inode, I_A | I_B)
> > inode->i_state = I_A | I_B => inode_state_set(inode, I_A | I_B)
> > [/quote]
>
> Drive-by bikeshedding: s/set/replace/g
>
> "replace" removes ambiguity with the concept of setting a bit ( |= ). An
> alternative would be "set_only".
>
I agree _set may be ambiguous here. I was considering something like
_assign or _set_value instead.
I'm not that fond of _replace but I'm not going to really going to
argue about any particular variant.
The good news is that whatever the naming, sed indeed can be used to
adjust the patchset. :)
Powered by blists - more mailing lists