Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752221AbdLFT5v (ORCPT ); Wed, 6 Dec 2017 14:57:51 -0500 Received: from mail-lf0-f67.google.com ([209.85.215.67]:44713 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751610AbdLFT5r (ORCPT ); Wed, 6 Dec 2017 14:57:47 -0500 X-Google-Smtp-Source: AGs4zMbGr3g+Rzzwccw9WFoSbDiQUjRpiM8tNhgqMrZFqX3DveJ1i42o5g5+5IwVQAm90zys7qwFSA== Date: Wed, 6 Dec 2017 20:57:42 +0100 From: Simon =?utf-8?Q?Sandstr=C3=B6m?= To: Dan Carpenter Cc: Marcus Wolf , gregkh@linuxfoundation.org, devel@driverdev.osuosl.org, linux@Wolf-Entwicklungen.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in rf69_enum.h Message-ID: <20171206195742.my5huetlwqk7bbqb@kappa.nikanor.nu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171206104414.xv2yqldf5xjovxxr@mwanda> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1103 Lines: 37 On Wed, Dec 06, 2017 at 01:44:14PM +0300, Dan Carpenter wrote: > On Wed, Dec 06, 2017 at 12:31:31PM +0200, Marcus Wolf wrote: > > > > > > Am 06.12.2017 um 12:23 schrieb Dan Carpenter: > > > > > > > > > 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 > Hi, I'm not sure about this so I have to ask: wouldn't the header need to be in include/uapi/ for userspace to use them? Or is it "allowed" for userspace programs to use this internal header? Or are we afraid to break userspace programs that keeps a copy of pi433_if.h? Regards, Simon