linux-kernel - Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171204195613.amlez432beq72t7j@mwanda>
Date:   Mon, 4 Dec 2017 22:56:13 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Marcus Wolf <marcus.wolf@...rthome-wolf.de>
Cc:     devel@...verdev.osuosl.org, gregkh@...uxfoundation.org,
        linux@...f-Entwicklungen.de, linux-kernel@...r.kernel.org,
        Simon Sandström <simon@...anor.nu>
Subject: Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

On Mon, Dec 04, 2017 at 09:31:06PM +0200, Marcus Wolf wrote:
> > > Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
> > 
> > That's future code so we can delete that sentence for now.
> 
> With the rule above, you are absolutely right. But we now spend time, to
> remove an currently non necessary feature ("double layer"), which will take
> time to re-introduce as soon, as someone wants to support a second chip.
> Isn't that double-work and a thus a pitty?
> 

It is what it is...  In the kernel we insist all code have a user right
now when it's merged.  Unused code or future code is deleted.  We hate
abstraction layers.  Everyone argues that their abstraction layer is
different and good but kernel devs instinctively hate abstraction.

To be honest, in the kernel we do do a lot of work twice.  I made people
redo 9 quite large patches for this pi4333 driver today.  And they're
probably going end up conflicting and have to be redone again...  :/
That does suck.  I don't know what to do about it.

In my view it helps that people sending patches don't ever have to worry
about future code and we can focus on what exists now.  Greg will never
reject code for "future reasons" unless the future is almost right away
like tomorrow or maybe the next day.

regards,
dan carpenter