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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
