Re: [PATCH net-next v6 1/5] net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames

[Jakub Kicinski]

On Sat, 31 Oct 2020 15:47:28 -0400 Willem de Bruijn wrote:
> On Sat, Oct 31, 2020 at 12:02 PM Xie He <xie.he.0141@xxxxxxxxx> wrote:
> > On Sat, Oct 31, 2020 at 8:18 AM Xie He <xie.he.0141@xxxxxxxxx> wrote:  
> > > > Especially without that, I'm not sure this and the follow-on patch add
> > > > much value. Minor code cleanups complicate backports of fixes.  
> > >
> > > To me this is necessary, because I feel hard to do any development on
> > > un-cleaned-up code. I really don't know how to add my code without
> > > these clean-ups, and even if I managed to do that, I would not be
> > > happy with my code.  
> 
> That is the reality of working in this space, I think. I have
> frequently restructured code, fixed a bug and then worked backwards to
> create a *minimal* bugfix that applies to the current code as well as
> older stable branches.
> 
> Obviously this is more of a concern for stable fixes than for new
> code. But we have to keep in mind that every code churn will make
> future bug fixes harder to roll out to users. That is not to say that
> churn should be avoided, just that we need to balance a change's
> benefit against this cost.
> 
> > And always keeping the user interface and even the code unchanged
> > contradicts my motivation of contributing to the Linux kernel. All my
> > contributions are motivated by the hope to clean things up. I'm not an
> > actual user of any of the code I contribute. If we adhere to the
> > philosophy of not doing any clean-ups, my contributions would be
> > meaningless.  
> 
> There are cleanups and cleanups. Dead code removal and deduplication
> of open coded logic, for instance, are very valuable. As is, for
> instance, your work in making sense of hard_header_len.

Or removing the buggy uses of IFF_TX_SKB_SHARING, for that matter
(which at this point I agree we should just remove from ether_setup, 
and let people who care re-enable it).

> Returning code in branches vs an error jump label seems more of a
> personal preference, and to me does not pass the benefit/cost threshold.

I must agree.