Re: git: 2c2ef670a79b - main - pseudofs: use the vget_prep/vget_finish idiom

On Thu, Sep 22, 2022 at 3:11 AM Mateusz Guzik <mjguzik@gmail.com> wrote:

> 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.
>
>
Maybe you can easily see so, and maybe I can easily see so as well.
But it is not guaranteed to be the case for everyone looking at the commit
history.
The "what" of the commit is contained in the commit itself, but the "why"
can easily
be lost to the depths of time; that is why I see it as more important to
record in the commit
message.

Indeed, when I was left here to guess at the "why", I got it wrong!  So is
it so hard to add
another sentence or even a clause like "an easy microoptimization" to the
commit message?
Having some hint at the "why" greatly improves the quality of the record
that is the commit.




> 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).
>
>

I did not say that the VFS itself was great to develop, but rather that my
experience as a filesystem author has been good ("develop for" vs "develop"
is
an unfortunately subtle distinction in English).  I consider my point above
about
including "why" in the commit message to be far more important than this
part,
which was just an attempt to add some motivation as to why I personally
care.
Other people have other good reasons to want to include the "why" in the
commit
message, that I surely did not cover fully here.


> 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).
>
>
Okay, thank you for letting me know.  It is reassuring for my own personal
situation with OpenAFS.


> 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.
>
>

That's your prerogative, and I won't attempt to force you to do otherwise.
For myself, I find that having even a barebones doc has been incredibly
helpful when I come back to the work 3-5 years down the line, let alone when
I am looking at stuff someone else did 3-5 years previously.  Getting
things done
is great, and knowing the overall state of the project as it evolves is
also great.


> 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.
>
>

Okay.   Thank you.

-Ben