Re: [PATCH 03/20] [media] lirc.h: remove several unused ioctls

[Mauro Carvalho Chehab <mchehab@s-opensource.com>]

Em Tue, 12 Jul 2016 14:54:38 +0100
Sean Young <sean@mess.org> escreveu:

> On Tue, Jul 12, 2016 at 02:35:56PM +0100, Sean Young wrote:
> > On Tue, Jul 12, 2016 at 10:23:00AM -0300, Mauro Carvalho Chehab wrote:  
> > > Em Tue, 12 Jul 2016 14:14:06 +0100
> > > Sean Young <sean@mess.org> escreveu:  
> > > > On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:  
> > -snip-  
> > > > > -#define LIRC_SET_REC_DUTY_CYCLE        _IOW('i', 0x00000016, __u32)    
> > > > 
> > > > Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> > > > LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.  
> > > 
> > > Removing the "LIRC_CAN" macros can break userspace, as some app could
> > > be using it to print the LIRC features. That's why I opted to keep
> > > them, but to document that those features are unused - this is at
> > > the next patch (04/20).  
> > 
> > How is that different from removing the ioctls? Might as well go the whole
> > hog.  

If someone implemented LIRC_GET_FEATURES and handled all flags, such
program would break, as the API change.

> 
> Ah you meant that if someone later adds a new feature then we might reuse
> an existing bit. Oops, sorry.

Yes, this is another possibility. In such case, the ABI will also 
break, with is more severe than a pure API change.

Removing the ioctl declarations will still work for compiled programs,
as they'll still receive an error code when the ioctl is issued.

> 
> > Also note that LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as
> > LIRC_CAN_MEASURE_CARRIER, so if some userspace program uses this it might
> > end up in the mistaken belief its supports LIRC_CAN_SET_REC_DUTY_CYCLE.  
> 
> So there is an argument for removing LIRC_CAN_SET_REC_DUTY_CYCLE, but
> that should be a separate patch.

Yes. Yet, IMHO, the best would be to put those unused LIRC_CAN into a:

#ifndef __KERNEL

macro block, to:

1) avoid the risk of breaking userspace;
2) be clear that those are deprecated stuff and should not be used on
   newer programs;
3) Reserve the bits for not be used, to avoid possible conflicts.

Regards,
Mauro