Date: Thu, 22 Sep 2022 12:11:26 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Benjamin Kaduk <bjkfbsd@gmail.com> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 2c2ef670a79b - main - pseudofs: use the vget_prep/vget_finish idiom Message-ID: <CAGudoHF1peBhw03ucSv%2B8eGdkC5=Fq_sOjPWjjd6iqtu44qgDw@mail.gmail.com> In-Reply-To: <CAJ5_RoA4=NqQ-XZ52rJ7J1xJMUg2U=kB%2B7b_x5sLHXFsJGwVSg@mail.gmail.com> References: <202209192009.28JK924f075123@gitrepo.freebsd.org> <CAJ5_RoA4=NqQ-XZ52rJ7J1xJMUg2U=kB%2B7b_x5sLHXFsJGwVSg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/19/22, Benjamin Kaduk <bjkfbsd@gmail.com> wrote: > On Mon, Sep 19, 2022 at 1:09 PM Mateusz Guzik <mjg@freebsd.org> wrote: > >> The branch main has been updated by mjg: >> >> URL: >> https://cgit.FreeBSD.org/src/commit/?id=2c2ef670a79b7f8fa84796a04885a3f76c914762 >> >> commit 2c2ef670a79b7f8fa84796a04885a3f76c914762 >> Author: Mateusz Guzik <mjg@FreeBSD.org> >> AuthorDate: 2022-09-19 20:07:10 +0000 >> Commit: Mateusz Guzik <mjg@FreeBSD.org> >> CommitDate: 2022-09-19 20:08:40 +0000 >> >> pseudofs: use the vget_prep/vget_finish idiom >> >> > > Picking an arbitrary commit to reply to: could you please add a bit more > detail about the "why" to commit messages in the future? > Having looked a little bit, it seems that this would be "as part of the > broader effort to remove the vnode interlock [from a specific class of > operations?]". A pointer to a bigger-picture doc would be great as well. The idiom at hand is over 3 years old now and employing it at this point should not require a justification. One can easily see not taking the interlock is faster both single- and multi-threaded, which makes the change worthwhile regardless of support for the flag in locking primitives going away or not. So happens I'm going to keep the flag support in vget itself for the time being. > I co-maintain an out-of-tree filesystem and commit messages like this make > it really hard for me to get a handle on whether I need to do anything and, > if so, where to start looking to find out what to do. An overall project > page would be a great reference, or even comment around the implementations > that points to a key differential revision that implemented the core > behavior. One of the things that's been really nice about developing for > the FreeBSD VFS in the past is how easy it is to determine what a > filesystem implementation needs to provide, and I'd love to see us continue > that tradition. > I'm definitely confused by this comment. VFS has rampant layering violations, including wtfs like filesystems sneaking in their own changes to cn_flags by literally or-ing into it mid-lookup (recently fixed, see 5b5b7e2ca2fa9a2418dd51749f4ef6f881ae7179) or leaking their internals out and consequently imposing completely unnecessary restrictions on the layer (see a comment above vput_final for an example). That said, the changes I normally made are either backwards-compatible or are guaranteed to blow up at compilation time (or worst case at runtime with an assert). I agree some form a general doc would be nice, but between spending time writing one or actually getting things done, I chose the latter. There are several filesystems which I have no intent in modifying beyond bare minimum to keep them operational, thus general theme of backwards compat will continue. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHF1peBhw03ucSv%2B8eGdkC5=Fq_sOjPWjjd6iqtu44qgDw>