lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <311D4948-8EE4-4A84-A2C4-6B104CEDB81C@nutanix.com> Date: Thu, 8 May 2025 13:45:42 +0000 From: Jon Kohler <jon@...anix.com> To: Willem de Bruijn <willemdebruijn.kernel@...il.com> CC: "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, Eugenio Pérez <eperezma@...hat.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "bpf@...r.kernel.org" <bpf@...r.kernel.org> Subject: Re: [PATCH net-next] vhost/net: align variable names with XDP terminology > On May 8, 2025, at 9:42 AM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote: > > > Jon Kohler wrote: >> >> >>> On May 7, 2025, at 1:23 PM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote: >>> > > Minor: can you fix email to avoid the above? I think its a corporate email thing, but good reminder, ill clip it out in future responses to not pollute the list > >>> Jon Kohler wrote: >>>> Refactor variable names in vhost_net_build_xdp to align with XDP >>>> terminology, enhancing code clarity and consistency. Additionally, >>>> reorder variables to follow a reverse Christmas tree structure, >>>> improving code organization and readability. >>>> >>>> This change introduces no functional modifications. >>>> >>>> Signed-off-by: Jon Kohler <jon@...anix.com> >>> >>> We generally don't do pure refactoring patches. >>> >>> They add churn to code history for little gain (and some >>> overhead and risk). >>> >> >> Ok, I’ll club this together with the larger change I’m working on >> for multi-buffer support in vhost/net, ill send that as a series >> when it is ready for eyes > > I forgot to add that it makes stable fixes harder to apply across > LTS, distro and other derived kernels. > > So resist the urge the just make stylistic changes. Functional > improvements warrants the risk, churn and extra work. > Fair enough, I think this will make more sense in the context of the broader series which will end up re-writing the majority of this func. Was trying to separate some of the prep patches, but I see what you're saying.
Powered by blists - more mailing lists