Re: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri September 14 2012 23:05:45 Sakari Ailus wrote:
> Hi Rémi,
> 
> Rémi Denis-Courmont wrote:
> > Le vendredi 14 septembre 2012 23:25:01, Sakari Ailus a écrit :
> >> I had a quick discussion with Laurent, and what he suggested was to use
> >> the kernel version to figure out the type of the timestamp. The drivers
> >> that use the monotonic time right now wouldn't be affected by the new
> >> flag on older kernels. If we've decided we're going to switch to
> >> monotonic time anyway, why not just change all the drivers now and
> >> forget the capability flag.
> >
> > That does not work In Real Life.
> >
> > People do port old drivers forward to new kernels.
> > People do port new drivers back to old kernels
> 
> Why would you port a driver from an old kernel to a new kernel? Or are 
> you talking about out-of-tree drivers?

More likely the latter.

> If you do port drivers across different kernel versions I guess you're 
> supposed to use the appropriate interfaces for those kernels, too. Using 
> a helper function helps here, so compiling a backported driver would 
> fail w/o the helper function that produces the timestamp, forcing the 
> backporter to notice the situation.
> 
> Anyway, I don't have a very strict opinion on this, so I'm okay with the 
> flag, too, but I personally simply don't think it's the best choice we 
> can make now. Also, without converting the drivers now the user space 
> must live with different kinds of timestamps much longer.

There are a number of reasons why I want to go with a flag:

- Out-of-tree drivers which are unlikely to switch to monotonic in practice
- Backporting drivers
- It makes it easy to verify in v4l2-compliance and enforce the use of
  the monotonic clock.
- It's easy for apps to check.

The third reason is probably the most important one for me. There tends to
be a great deal of inertia before changes like this are applied to new drivers,
and without being able to (easily) check this in v4l2-compliance more drivers
will be merged that keep using gettimeofday. It's all too easy to miss in a
review.

That doesn't mean that it isn't a good idea to convert existing drivers asap.
But it's not something I'm likely to take up myself.

Creating a small helper function as you suggested elsewhere is a good idea as
well. I'll write something for that.

Regards,

	Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux