Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in rf69_enum.h

[Marcus Wolf]

Am 06.12.2017 um 21:57 schrieb Simon SandstrÃm:
> 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

Hi Simon,

in principle, I think you are right. With my first patch, offering the 
driver I did it that way, but Greg asked me to migrate everything 
(including docu) into staging/pi433. I think, that's related to being in 
staging.
At the moment, I copy pi433_if.h and rf69_enum.h to my userspace 
program, in order to be able to compile it.

To be honest, I am a little bit astonished about that question. Don't 
you do a regression test after such a redesign? I would be a little bit 
afraid to offer such redesign without testing.


Regards,
Marcus