Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752261AbdLDT4h (ORCPT ); Mon, 4 Dec 2017 14:56:37 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:51574 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751950AbdLDT4g (ORCPT ); Mon, 4 Dec 2017 14:56:36 -0500 Date: Mon, 4 Dec 2017 22:56:13 +0300 From: Dan Carpenter To: Marcus Wolf Cc: devel@driverdev.osuosl.org, gregkh@linuxfoundation.org, linux@Wolf-Entwicklungen.de, linux-kernel@vger.kernel.org, Simon =?iso-8859-1?Q?Sandstr=F6m?= Subject: Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h Message-ID: <20171204195613.amlez432beq72t7j@mwanda> References: <20171203151726.16639-1-simon@nikanor.nu> <20171203151726.16639-6-simon@nikanor.nu> <20171204102419.onpiyz2dpos4ooc5@mwanda> <20171204192144.wnpcugnc23dohi7w@mwanda> <74a6813f-e7ad-e0e8-ca3d-392689664894@smarthome-wolf.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74a6813f-e7ad-e0e8-ca3d-392689664894@smarthome-wolf.de> User-Agent: NeoMutt/20170609 (1.8.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8735 signatures=668637 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712040281 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1309 Lines: 28 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