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

[Marcus Wolf <marcus.wolf@smarthome-wolf.de>]

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