Date: Sat, 24 Sep 2022 09:42:14 -0700 From: Benjamin Kaduk <bjkfbsd@gmail.com> To: Mateusz Guzik <mjguzik@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: <CAJ5_RoBPt9uFWbTk9N=Gc=SV6i1ZySrh7hZ6rfdh_bV9ixu67Q@mail.gmail.com> In-Reply-To: <CAGudoHF1peBhw03ucSv%2B8eGdkC5=Fq_sOjPWjjd6iqtu44qgDw@mail.gmail.com> References: <202209192009.28JK924f075123@gitrepo.freebsd.org> <CAJ5_RoA4=NqQ-XZ52rJ7J1xJMUg2U=kB%2B7b_x5sLHXFsJGwVSg@mail.gmail.com> <CAGudoHF1peBhw03ucSv%2B8eGdkC5=Fq_sOjPWjjd6iqtu44qgDw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000b4db6905e96efa1e Content-Type: text/plain; charset="UTF-8" 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 --000000000000b4db6905e96efa1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Thu, Sep 22, 2022 at 3:11 AM Mateusz G= uzik <<a href=3D"mailto:mjguzik@gmail.com">mjguzik@gmail.com</a>> wro= te:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex">On 9/19/22, Benjamin Kaduk <<a href=3D"mailto:bjkfbsd@gma= il.com" target=3D"_blank">bjkfbsd@gmail.com</a>> wrote:<br> > On Mon, Sep 19, 2022 at 1:09 PM Mateusz Guzik <<a href=3D"mailto:mj= g@freebsd.org" target=3D"_blank">mjg@freebsd.org</a>> wrote:<br> ><br> >> The branch main has been updated by mjg:<br> >><br> >> URL:<br> >> <a href=3D"https://cgit.FreeBSD.org/src/commit/?id=3D2c2ef670a79b7= f8fa84796a04885a3f76c914762" rel=3D"noreferrer" target=3D"_blank">https://c= git.FreeBSD.org/src/commit/?id=3D2c2ef670a79b7f8fa84796a04885a3f76c914762</= a><br> >><br> >> commit 2c2ef670a79b7f8fa84796a04885a3f76c914762<br> >> Author:=C2=A0 =C2=A0 =C2=A0Mateusz Guzik <mjg@FreeBSD.org><b= r> >> AuthorDate: 2022-09-19 20:07:10 +0000<br> >> Commit:=C2=A0 =C2=A0 =C2=A0Mateusz Guzik <mjg@FreeBSD.org><b= r> >> CommitDate: 2022-09-19 20:08:40 +0000<br> >><br> >>=C2=A0 =C2=A0 =C2=A0pseudofs: use the vget_prep/vget_finish idiom<b= r> >><br> >><br> ><br> > Picking an arbitrary commit to reply to: could you please add a bit mo= re<br> > detail about the "why" to commit messages in the future?<br> > Having looked a little bit, it seems that this would be "as part = of the<br> > broader effort to remove the vnode interlock [from a specific class of= <br> > operations?]".=C2=A0 A pointer to a bigger-picture doc would be g= reat as well.<br> <br> The idiom at hand is over 3 years old now and employing it at this<br> point should not require a justification.<br> <br> One can easily see not taking the interlock is faster both single- and<br> multi-threaded, which makes the change worthwhile regardless of<br> support for the flag in locking primitives going away or not.<br> <br></blockquote><div><br></div><div>Maybe you can easily see so, and maybe= I can easily see so as well.</div><div>But it is not guaranteed to be the = case for everyone looking at the commit history.</div><div>The "what&q= uot; of the commit is contained in the commit itself, but the "why&quo= t; can easily</div><div>be lost to the depths of time; that is why I see it= as more important to record in the commit</div><div>message.</div><div><br= ></div><div>Indeed, when I was left here to guess at the "why", I= got it wrong!=C2=A0 So is it so hard to add</div><div>another sentence or = even a clause like "an easy microoptimization" to the commit mess= age?</div><div>Having some hint at the "why" greatly improves the= quality of the record that is the commit.</div><div><br></div><div><br></d= iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> So happens I'm going to keep the flag support in vget itself for the ti= me being.<br> <br> > I co-maintain an out-of-tree filesystem and commit messages like this = make<br> > it really hard for me to get a handle on whether I need to do anything= and,<br> > if so, where to start looking to find out what to do.=C2=A0 An overall= project<br> > page would be a great reference, or even comment around the implementa= tions<br> > that points to a key differential revision that implemented the core<b= r> > behavior.=C2=A0 One of the things that's been really nice about de= veloping for<br> > the FreeBSD VFS in the past is how easy it is to determine what a<br> > filesystem implementation needs to provide, and I'd love to see us= continue<br> > that tradition.<br> ><br> <br> I'm definitely confused by this comment. VFS has rampant layering<br> violations, including wtfs like filesystems sneaking in their own<br> changes to cn_flags by literally or-ing into it mid-lookup (recently<br> fixed, see 5b5b7e2ca2fa9a2418dd51749f4ef6f881ae7179) or leaking their<br> internals out and consequently imposing completely unnecessary<br> restrictions on the layer (see a comment above vput_final for an<br> example).<br> <br></blockquote><div><br></div><div><br></div><div>I did not say that the = VFS itself was great to develop, but rather that my</div><div>experience as= a filesystem author has been good ("develop for" vs "develo= p" is</div><div>an unfortunately subtle distinction in English).=C2=A0= I consider my point above about</div><div>including "why" in the= commit message to be far more important than this part,</div><div>which wa= s just an attempt to add some motivation as to why I personally care.</div>= <div>Other people have other good reasons to want to include the "why&= quot; in the commit</div><div>message, that I surely did not cover fully he= re.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= > That said, the changes I normally made are either backwards-compatible<br> or are guaranteed to blow up at compilation time (or worst case at<br> runtime with an assert).<br> <br></blockquote><div><br></div><div>Okay, thank you for letting me know.= =C2=A0 It is reassuring for my own personal situation with OpenAFS.</div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I agree some form a general doc would be nice, but between spending<br> time writing one or actually getting things done, I chose the latter.<br> <br></blockquote><div><br></div><div><br></div><div>That's your preroga= tive, and I won't attempt to force you to do otherwise.</div><div>For m= yself, I find that having even a barebones doc has been incredibly</div><di= v>helpful when I come back to the work 3-5 years down the line, let alone w= hen</div><div>I am looking at stuff someone else did 3-5 years previously.= =C2=A0 Getting things done</div><div>is great, and knowing the overall stat= e of the project as it evolves is also great.</div><div>=C2=A0</div><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p= x solid rgb(204,204,204);padding-left:1ex"> There are several filesystems which I have no intent in modifying<br> beyond bare minimum to keep them operational, thus general theme of<br> backwards compat will continue.<br><br></blockquote><div><br></div><div><br= ></div><div>Okay.=C2=A0 =C2=A0Thank you.</div><div><br></div><div>-Ben</div= ></div></div> --000000000000b4db6905e96efa1e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoBPt9uFWbTk9N=Gc=SV6i1ZySrh7hZ6rfdh_bV9ixu67Q>