linux-kernel - Re: [PATCH] net: phylink: Separating two unrelated definitions for improving code readability

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241121125458.j237l34kw3uxhskz@skbuf>
Date: Thu, 21 Nov 2024 14:54:58 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Cong Yi <yicong.srfy@...mail.com>, andrew@...n.ch, hkallweit1@...il.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	yicong@...inos.cn
Subject: Re: [PATCH] net: phylink: Separating two unrelated definitions for
 improving code readability

On Thu, Nov 21, 2024 at 12:49:43PM +0000, Russell King (Oracle) wrote:
> On Thu, Nov 21, 2024 at 02:47:18PM +0200, Vladimir Oltean wrote:
> > On Thu, Nov 21, 2024 at 12:26:44PM +0000, Russell King (Oracle) wrote:
> > > On Thu, Nov 21, 2024 at 02:15:48PM +0200, Vladimir Oltean wrote:
> > > > On Thu, Nov 21, 2024 at 12:11:02PM +0000, Russell King (Oracle) wrote:
> > > > > On Thu, Nov 21, 2024 at 01:52:30PM +0200, Vladimir Oltean wrote:
> > > > > > I don't understand what's to defend about this, really.
> > > > > 
> > > > > It's not something I want to entertain right now. I have enough on my
> > > > > plate without having patches like this to deal with. Maybe next year
> > > > > I'll look at it, but not right now.
> > > > 
> > > > I can definitely understand the lack of time to deal with trivial
> > > > matters, but I mean, it isn't as if ./scripts/get_maintainer.pl
> > > > drivers/net/phy/phylink.c lists a single person...
> > > 
> > > Trivial patches have an impact beyond just reviewing the patch. They
> > > can cause conflicts, causing work that's in progress to need extra
> > > re-work.
> > > 
> > > I have the problems of in-band that I've been trying to address since
> > > April. I have phylink EEE support that I've also been trying to move
> > > forward. However, with everything that has happened this year (first,
> > > a high priority work item, followed by holiday, followed by my eye
> > > operations) I've only _just_ been able to get back to looking at these
> > > issues... meanwhile I see that I'm now being asked for stuff about
> > > stacked PHYs which is also going to impact phylink. Oh, and to top it
> > > off, I've discovered that mainline is broken on my test platform
> > > (IRQ crap) which I'm currently trying to debug what has been broken.
> > > Meaning I'm not working on any phylink stuff right now because of
> > > other people's breakage.
> > > 
> > > It's just been bit of crap after another after another.
> > > 
> > > Give me a sodding break.
> > 
> > I just believe that any patch submitter has the right for their proposal
> > to be evaluated based solely on its own merits (even if time has to be
> > stretched in order for that to happen), not based on unrelated context.
> 
> Right, and my coding preference is as I've written the code. If my
> coding preference, as author and maintainer of this file, were
> different then I would've written it differently.
> 
> Am I not entitled to make my own choices for code I maintain?

Well, yes, I do believe that's the essence of our disagreement. I would
very much like phylink to not be the personal island of Russell King the
individual, but open to common patterns adopted across the entire
networking subsystem, and especially to other individuals. You've quoted
ata headers as an example of a similar pattern, but "git blame" says
that comes from pre-history, so I'm not sure it's exactly the best example
of what to do today.