[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171206195742.my5huetlwqk7bbqb@kappa.nikanor.nu>
Date: Wed, 6 Dec 2017 20:57:42 +0100
From: Simon Sandström <simon@...anor.nu>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: Marcus Wolf <marcus.wolf@...rthome-wolf.de>,
gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
linux@...f-Entwicklungen.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in
rf69_enum.h
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
Powered by blists - more mailing lists