Date: Thu, 7 Oct 2021 08:32:06 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Alexey Dokuchaev <danfe@freebsd.org>, Kyle Evans <kevans@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-branches@freebsd.org Subject: Re: git: 000aad3d093a - stable/12 - loader: allocate properly aligned buffer for network packet Message-ID: <CANCZdfrRgk_pw4391_-1d155ZD2j%2BhOMNifPcVt6GhqW34VymA@mail.gmail.com> In-Reply-To: <2898a7a27162e1ba0cd0d93b99b0975f8ad65ff5.camel@freebsd.org> References: <202110070337.1973bgRH073900@gitrepo.freebsd.org> <YV6OVKE6dNy%2BkigE@FreeBSD.org> <CACNAnaFqymg6QQa1ATd0dyreXBa0-u-5Hb=kjjs2igjASFRwEw@mail.gmail.com> <YV6Yrede5/x5NM7E@FreeBSD.org> <2898a7a27162e1ba0cd0d93b99b0975f8ad65ff5.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000033ee3505cdc42165 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 7, 2021 at 8:26 AM Ian Lepore <ian@freebsd.org> wrote: > On Thu, 2021-10-07 at 06:50 +0000, Alexey Dokuchaev wrote: > > On Thu, Oct 07, 2021 at 01:20:05AM -0500, Kyle Evans wrote: > > > On Thu, Oct 7, 2021 at 1:06 AM Alexey Dokuchaev wrote: > > > > On Thu, Oct 07, 2021 at 03:37:42AM +0000, Kyle Evans wrote: > > > > > commit 000aad3d093a376bb1104a284b4102149db43155 > > > > > > > > > > loader: allocate properly aligned buffer for network packet > > > > > > > > > > Use memalign(4, size) to ensure we have properly aligned > > > > > buffer. > > > > > > > > > > (cherry picked from commit > > > > > 659bf32dfc595b6cd6aeda7f05cb57872c64d2d1) > > > > > > > > I don't understand, so this is a merge of the commit from master > > > > (main) to > > > > stablle/12 which had then been reverted? So why do the merge in > > > > the first > > > > place? > > > > > > Because commit + revert pairs are noise in the MFC tracker that > > > distracts from actual candidates for merging. > > > > Sounds like MFC tracker should be fixed then, as now it is noise in > > the tool (tracker) vs. noise in the branch. Tools come and go, and > > code stays forever. > > > > ./danfe > > I completely disagree, and used to do this kind of mfc even before the > nifty mfc tracker came along. I see merging to older branches as a > process of replaying the commits that happened on the main branch, and > if that involves reverting and recommitting, I replay those too. > With git, though, we can squash the commits together and include muliple cherry-picked lines. This can be part of the replaying process and git supports us improving our process for things like this. Now, one could argue that the MFC track could also be improved, and that's true. However, there's other tools than just the MFC tracker that would need updating and some careful thought to balance all the concerns needs to take place, I think. What Kyle did is fine. It isn't terrible. Neither is it perfect, but it is well within the range of acceptable choices we have today. At the same time, it does highlight we could do a bit better, perhaps. Absent any guidance, though, I don't think we can expect much better. I'll add this as a possible area to explore in the git working group. Warner --00000000000033ee3505cdc42165--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrRgk_pw4391_-1d155ZD2j%2BhOMNifPcVt6GhqW34VymA>