Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755041AbdLFLHp convert rfc822-to-8bit (ORCPT ); Wed, 6 Dec 2017 06:07:45 -0500 Received: from dd39320.kasserver.com ([85.13.155.146]:58266 "EHLO dd39320.kasserver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754858AbdLFLHl (ORCPT ); Wed, 6 Dec 2017 06:07:41 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in rf69_enum.h From: Marcus Wolf X-Mailer: iPhone Mail (14E304) In-Reply-To: <20171206104414.xv2yqldf5xjovxxr@mwanda> Date: Wed, 6 Dec 2017 12:07:39 +0100 Cc: =?utf-8?Q?Simon_Sandstr=C3=B6m?= , gregkh@linuxfoundation.org, devel@driverdev.osuosl.org, linux@Wolf-Entwicklungen.de, linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <06217224-2BBC-4585-8F0D-62E9788CDBFB@Smarthome-Wolf.de> References: <20171205220849.5486-1-simon@nikanor.nu> <20171205220849.5486-5-simon@nikanor.nu> <4c89dc10-ccce-7760-f806-3a19c3edf743@smarthome-wolf.de> <20171206100833.3ficksukt6xaazl4@mwanda> <2ebc402d-f2af-40cb-7aa2-c9f062a0dd3d@smarthome-wolf.de> <20171206104414.xv2yqldf5xjovxxr@mwanda> To: Dan Carpenter Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1876 Lines: 64 Sorry, for sending HTML as well - I am writing from my phone... Yes, you will break something, when renaming. Since order isn't changed, most probably old programs will still compile with old enum.h. If we want to move from optionOnOff to bool, we will also break old progs. Since driver is new (mainline for just something like 2 monthes) and stil under devel, I think we should "risk" it. Gruß, Marcus > Am 06.12.2017 um 11:44 schrieb Dan Carpenter : > >> On Wed, Dec 06, 2017 at 12:31:31PM +0200, Marcus Wolf wrote: >> >> >>> Am 06.12.2017 um 12:23 schrieb Dan Carpenter: >>> On Wed, Dec 06, 2017 at 11:46:41AM +0200, Marcus Wolf wrote: >>>>> diff --git a/drivers/staging/pi433/rf69_enum.h b/drivers/staging/pi433/rf69_enum.h >>>>> index babe597e2ec6..5247e9269de9 100644 >>>>> --- a/drivers/staging/pi433/rf69_enum.h >>>>> +++ b/drivers/staging/pi433/rf69_enum.h >>>>> @@ -18,9 +18,9 @@ >>>>> #ifndef RF69_ENUM_H >>>>> #define RF69_ENUM_H >>>>> -enum optionOnOff { >>>>> - optionOff, >>>>> - optionOn >>>>> +enum option_on_off { >>>>> + OPTION_OFF, >>>>> + OPTION_ON >>>>> }; >>>>> enum mode { >>>>> >>>> >>>> Hi Simon, >>>> >>>> nice work. >>>> >>>> Thank you very much for all the style fixes :-) >>>> >>> >>> >>> Wow... This was the one patch I thought was going to sink this >>> patchset... >> >> I don't get that. What do you mean? >> >>> Isn't enum optionOnOff part of the userspace headers? >>> >>> I thought we weren't allowed to change that. >> >> All enums are for user space (or inteded to be used in userspace in future). >> Didn't introduce enums for internal use. > > So what I'm asking is if we do this change, does it break any userspace > programs which are used *right now*. In other words will programs stop > compiling because we've renamed an enum? > > regards, > dan carpenter