Re: [PATCH] media: v4l2-compat-ioctl32.c: copy reserved2 field in get_v4l2_buffer32

[Mauro Carvalho Chehab]

Hi Sunyoung,

Em Tue, 21 Apr 2020 12:33:42 +0900
"Sunyoung Kang" <sy0816.kang@xxxxxxxxxxx> escreveu:

> Thank you for your detailed guide.
> And I'll look into how to handle the additional information.

Please don't top post. See my comments below.

> 
> Thanks
> Sunyoung
> 
> > -----Original Message-----
> > From: Arnd Bergmann <arnd@xxxxxxxx>
> > Sent: Monday, April 20, 2020 8:23 PM
> > To: Sunyoung Kang <sy0816.kang@xxxxxxxxxxx>
> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Mauro Carvalho Chehab
> > <mchehab@xxxxxxxxxx>; Hans Verkuil <hverkuil-cisco@xxxxxxxxx>; Thomas
> > Gleixner <tglx@xxxxxxxxxxxxx>; Linux Media Mailing List <linux-  
> > media@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx  
> > Subject: Re: [PATCH] media: v4l2-compat-ioctl32.c: copy reserved2 field in
> > get_v4l2_buffer32
> > 
> > On Mon, Apr 20, 2020 at 2:40 AM Sunyoung Kang <sy0816.kang@xxxxxxxxxxx>
> > wrote:  
> > >
> > > I understand what you mean.
> > > However, the way to transmit information about the buffer is only
> > > flags in v4l2_buffer In flags in v4l2_buffer, there is no reserved bit
> > > field that can be used for custom.
> > > Additional information about the buffer is needed to provide various
> > > functions required by the customers but flags is not enough. So
> > > reserved2 is used as an alternative.
> > > Can you suggest a better opinion?  
> > 
> > If you have a driver that needs to pass additional information that is not
> > supported by the subsystem, this is generally either because there is
> > something wrong in the driver, or because there is something wrong in the
> > subsystem.
> > 
> > Whichever is at fault should be fixed. If it's the subsystem, then you
> > should explain why it's wrong and make a suggestion for how to address it,
> > e.g.
> > introducing a new ioctl command or redefining the reserved members to be
> > defined in the way you need.
> > 
> > In any case, the ioctl commands should be driver independent, so that any
> > hardware with the same feature as your driver can work with the same user
> > space.

I guess the problem here is that the driver that Sunyoung is working
is not upstream.

The right approach here is to upstream the driver. Once we see the code,
we can help addressing the issues. This could either involve using some
reserved space at the ioctl for some usage or propose some other solution
that would address your needs.

This has to be discussed case by case, as it is really hard to say what
to do with "additional information that is not supported by the subsystem".
What does that exactly means? We need to see the code to better understand
it ;-)

Thanks,
Mauro