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
| ||
|
Date: Sat, 30 Jan 2016 16:41:50 -0200 From: Lucas Tanure <tanure@...ux.com> To: Joe Perches <joe@...ches.com> Cc: Eric Dumazet <eric.dumazet@...il.com>, Patrick McHardy <kaber@...sh.net>, Pablo Neira Ayuso <pablo@...filter.org>, Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>, "David S . Miller" <davem@...emloft.net>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, coreteam@...filter.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 3/4] netfilter: ipv4: use preferred kernel types On Sat, Jan 30, 2016 at 4:26 PM, Joe Perches <joe@...ches.com> wrote: > On Sat, 2016-01-30 at 09:51 -0800, Eric Dumazet wrote: >> On Sat, 2016-01-30 at 12:05 -0200, Lucas Tanure wrote: >> > On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy <kaber@...sh.net> wrote: >> > > On 30.01, Lucas Tanure wrote: >> > > > As suggested by checkpatch.pl: >> > > > CHECK: Prefer kernel type 'uX' over 'uintX_t' >> > > >> > > You might have noticed we have literally hundreds of them spread over 100 >> > > files in the netfilter code. We'll gradually change them when the code is >> > > touched anyways. >> > > >> > > > net/ipv4/netfilter/ip_tables.c | 5 ++--- >> > > > 1 file changed, 2 insertions(+), 3 deletions(-) >> > >> > Yes, I checked that. But would be better to change that now? >> > Because: >> > - could take years to anyone to touch the code, as the code already >> > works very well >> > - be more standardized could facilitate reading the code >> > - It's a good way to encourage new people to contribute to the code >> > >> > Thanks! >> >> These changes are a pain for people having to constantly backport fixes >> into stable kernels, or rebase their patches before upstream >> submissions. >> >> Things like 'git cherry-pick' , 'git rebase' no longer work. >> This is a huge pain, and manual editing to resolve conflicts often >> add bugs. >> >> Really, do you believe the 'uX' over 'uintX_t' stuff really matters for >> people working on adding new features and fixing bugs ? >> >> I am certain that if you had to work like us, you would quickly see the >> utility of such changes is negative. >> >> Sure, new submissions should be clean, but 'fixing' old code is not >> worth it. > > That might depend on whether or not the linux kernel is > a "long-life project" and whether or no any old branch > of it is also important and sufficiently long-life. > > The active life of a backport branch for the linux kernel > seems to be 3 or 4 years. The linux kernel will likely > be useful for a few more decades beyond that. > > Complex and long-life projects like the linux kernel > might benefit more in code complexity reduction patches > like these rather than code stasis for backward porting > ease. > > In general, arguing for stasis leads to ossification, > slow decline. > > Change for change's sake is poor, but changes to reduce > complexity, improve maintainability (for some measure of > it) and especially improve performance should be > welcomed where feasible. > My goal was to improve maintainability for the code, and with time, contribute with meaningful code. As you might have noticed I didn't fix every checkpatch.pl warning and error. I just sent the ones that I thought would improve the maintainability. And backport fixes will always be a pain, no matter what. Thanks for all the comments. Sorry for anything.
Powered by blists - more mailing lists