From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 6/7] [RFC] [media]: v4l2: introduce v4l2_timeval Date: Tue, 15 Sep 2015 22:26:23 +0200 Message-ID: <2432018.5rA5LXfiBo@wuerfel> References: <1442332148-488079-1-git-send-email-arnd@arndb.de> <1442332148-488079-7-git-send-email-arnd@arndb.de> <55F846E7.2040006@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <55F846E7.2040006@xs4all.nl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" To: Hans Verkuil Cc: linux-samsung-soc@vger.kernel.org, Mauro Carvalho Chehab , y2038@lists.linaro.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org List-Id: linux-api@vger.kernel.org T24gVHVlc2RheSAxNSBTZXB0ZW1iZXIgMjAxNSAxODoyNzoxOSBIYW5zIFZlcmt1aWwgd3JvdGU6 Cj4gT24gMDkvMTUvMjAxNSAwNTo0OSBQTSwgQXJuZCBCZXJnbWFubiB3cm90ZToKPiA+IFRoZSB2 NGwyIEFQSSB1c2VzIGEgJ3N0cnVjdCB0aW1ldmFsJyB0byBjb21tdW5pY2F0ZSB0aW1lIHN0YW1w cyB0byB1c2VyCj4gPiBzcGFjZS4gVGhpcyBpcyBicm9rZW4gb24gMzItYml0IGFyY2hpdGVjdHVy ZXMgYXMgc29vbiBhcyB3ZSBoYXZlIGEgQyBsaWJyYXJ5Cj4gPiB0aGF0IGRlZmluZXMgdGltZV90 IGFzIDY0IGJpdCwgd2hpY2ggdGhlbiBjaGFuZ2VzIHRoZSBzdHJ1Y3R1cmUgbGF5b3V0IG9mCj4g PiBzdHJ1Y3QgdjRsMl9idWZmZXIuCj4gPiAKPiA+IEZvcnR1bmF0ZWx5LCBhbG1vc3QgYWxsIHY0 bDIgZHJpdmVycyB1c2UgbW9ub3RvbmljIHRpbWVzdGFtcHMgYW5kIGNhbGwKPiA+IHY0bDJfZ2V0 X3RpbWVzdGFtcCgpLCB3aGljaCBtZWFucyB0aGV5IGRvbid0IGFsc28gaGF2ZSBhIHkyMDM4IHBy b2JsZW0uCj4gPiBUaGlzIG1lYW5zIHdlIGNhbiBrZWVwIHVzaW5nIHRoZSBleGlzdGluZyBiaW5h cnkgbGF5b3V0IG9mIHRoZSBzdHJ1Y3R1cmUKPiA+IGFuZCBkbyBub3QgbmVlZCB0byB3b3JyeSBh Ym91dCBkZWZpbmluZyBhIG5ldyBrZXJuZWwgaW50ZXJmYWNlIGZvcgo+ID4gdXNlcmxhbmQgd2l0 aCA2NC1iaXQgdGltZV90Lgo+ID4gCj4gPiBBIHBvc3NpYmxlIGRvd25zaWRlIG9mIHRoaXMgYXBw cm9hY2ggaXMgdGhhdCBpdCBicmVha3MgYW55IHVzZXIgc3BhY2UKPiA+IHRoYXQgdHJpZXMgdG8g YXNzaWduIHRoZSB0aW1ldmFsIHN0cnVjdHVyZSByZXR1cm5lZCBmcm9tIHRoZSBrZXJuZWwKPiA+ IHRvIGFub3RoZXIgdGltZXZhbCwgb3IgdG8gcGFzcyBhIHBvaW50ZXIgdG8gaXQgaW50byBhIGZ1 bmN0aW9uIHRoYXQKPiA+IGV4cGVjdHMgYSB0aW1ldmFsLiBUaG9zZSB3aWxsIGNhdXNlIGEgYnVp bGQtdGltZSB3YXJuaW5nIG9yIGVycm9yCj4gPiB0aGF0IGNhbiBiZSBmaXhlZCB1cCBpbiBhIGJh Y2t3YXJkcyBjb21wYXRpYmxlIHdheS4KPiA+IAo+ID4gVGhlIGFsdGVybmF0aXZlIHRvIHRoaXMg cGF0Y2ggaXMgdG8gbGVhdmUgdGhlIHN0cnVjdHVyZSB1c2luZwo+ID4gJ3N0cnVjdCB0aW1ldmFs JywgYnV0IHRoZW4gd2UgaGF2ZSB0byByZXdvcmsgdGhlIGtlcm5lbCB0byBsZXQKPiA+IGl0IGhh bmRsZSBib3RoIDMyLWJpdCBhbmQgNjQtYml0IHRpbWVfdCBmb3IgMzItYml0IHVzZXIgc3BhY2UK PiA+IHByb2Nlc3Nlcy4KPiAKPiBDb29sLiBPbmx5IHRoaXMgbW9ybmluZyBJIHdhcyB0aGlua2lu ZyBhYm91dCB3aGF0IHdvdWxkIGJlIG5lZWRlZCBpbiB2NGwyCj4gdG8gYmUgeTIwMzggc2FmZSwg YW5kIGhlcmUgaXQgaXMhCgpOaWNlIQoKZndpdywgSSBhbHNvIGhhdmUgYSBsaXN0IG9mIGRyaXZl cnMgYXQKaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vc3ByZWFkc2hlZXRzL2QvMUhDWXdIWHhzNDhU c1RiNklHVWR1TmpRbm1mUnZNUHpDTjZUXzBZaVF3aXMvZWRpdD91c3A9c2hhcmluZwp3aGljaCBs aXN0cyBhbGwga25vd24gZmlsZXMgdGhhdCBzdGlsbCBuZWVkIGNoYW5naW5nLCBpbiBjYXNlIHlv dSBhcmUKd29uZGVyaW5nIHdoYXQgZWxzZSBuZWVkcyB0byBiZSBkb25lLCB0aG91Z2ggaXQgY3Vy cmVudGx5IG9ubHkgY292ZXJzCnRoaW5ncyB0aGF0IG5vYm9keSBzbyBmYXIgaGFzIHN0YXJ0ZWQg d29ya2luZyBvbiwgYW5kIEkgaGF2ZSBhIGNvdXBsZQpwYXRjaGVzIG9uIG15IGRpc2sgdGhhdCBu ZWVkIHBvbGlzaGluZyAoSSBwdXNoZWQgb3V0IHRoZSB2NGwyIHBvcnRpb24Kb2YgdGhhdCBhcyBh IHN0YXJ0KQoKPiA+IEBAIC04MzksNyArODQ1LDcgQEAgc3RydWN0IHY0bDJfYnVmZmVyIHsKPiA+ ICAJX191MzIJCQlieXRlc3VzZWQ7Cj4gPiAgCV9fdTMyCQkJZmxhZ3M7Cj4gPiAgCV9fdTMyCQkJ ZmllbGQ7Cj4gPiAtCXN0cnVjdCB0aW1ldmFsCQl0aW1lc3RhbXA7Cj4gPiArCXN0cnVjdCB2NGwy X3RpbWV2YWwJdGltZXN0YW1wOwo+ID4gIAlzdHJ1Y3QgdjRsMl90aW1lY29kZQl0aW1lY29kZTsK PiA+ICAJX191MzIJCQlzZXF1ZW5jZTsKPiA+ICAKPiA+IAo+IAo+IEkgc3VzcGVjdCB0aGF0IHF1 aXRlIGEgZmV3IGFwcHMgdXNlIGFzc2lnbiB0aGUgdGltZXN0YW1wIHRvIGFub3RoZXIgdGltZXZh bAo+IHN0cnVjdC4gQSBxdWljayBncmVwIGluIHY0bC11dGlscyAod2hpY2ggd2UgbWFpbnRhaW4p IHNob3dzIGF0IGxlYXN0IHR3byBvZgo+IHRob3NlIGFzc2lnbm1lbnRzLiBEaXR0byBmb3IgeGF3 dHYzLgoKT2ssIHRoYXQgaXMgdmVyeSBoZWxwZnVsIGluZm9ybWF0aW9uLCB0aGFua3MgZm9yIGZp bmRpbmcgdGhhdCEKCj4gU28gSSBkb24ndCB0aGluayB2NGwyX3RpbWV2YWwgaXMgYW4gb3B0aW9u IGFzIGl0IHdvdWxkIGJyZWFrIHVzZXJzcGFjZSB0b28gYmFkbHkuCgpBZ3JlZWQsIHdlIGRlZmlu aXRlbHkgZG9uJ3Qgd2FudCB0byBicmVhayBidWlsZGluZyB1c2VyIHNwYWNlIHdpdGgKZXhpc3Rp bmcgZW52aXJvbm1lbnRzLCBpLmUuIDY0LWJpdCBhcmNoaXRlY3R1cmVzLCBvciAzMi1iaXQgYXJj aGl0ZWN0dXJlcwp3aXRoIDMyLWJpdCB0aW1lX3QuCgo+IEFuIGFsdGVybmF0aXZlIHRvIHN1cHBv cnRpbmcgYSA2NC1iaXQgdGltZXZhbCBmb3IgMzItYml0IHVzZXJzcGFjZSBpcyB0byBtYWtlIGEK PiBuZXcgeTIwMzgtYXdhcmUgc3RydWN0IGFuZCBhIG5ldyBzZXQgb2YgaW9jdGxzIGFuZCB1c2Ug dGhpcyBvcHBvcnR1bml0eSB0byBjbGVhbgo+IHVwIGFuZCBleHRlbmQgdGhlIHY0bDJfYnVmZmVy IHN0cnVjdC4KPiAKPiBTbyBhbnkgMzItYml0IGFwcCB0aGF0IG5lZWRzIHRvIGJlIHkyMDM4IGNv bXBsaWFudCB3b3VsZCBqdXN0IHVzZSB0aGUgbmV3Cj4gc3RydWN0IGFuZCBpb2N0bHMuCj4gCj4g QnV0IHRoaXMgaXMgc29tZXRoaW5nIHRvIGRpc2N1c3MgYW1vbmcgdGhlIHY0bDIgZGV2ZWxvcGVy cy4KCk9rLiBXZSBnZW5lcmFsbHkgdG8gcmVxdWlyZSBhcyBmZXcgc291cmNlIGxldmVsIGNoYW5n ZXMgdG8gdXNlciBzcGFjZQphcyBwb3NzaWJsZSBmb3IgdGhlIGNvbnZlcnNpb24sIGFuZCB3ZSB3 YW50IHRvIG1ha2Ugc3VyZSB0aGF0IHdoZW4KdXNpbmcgYSAzMi1iaXQgbGliYyB3aXRoIDY0LWJp dCB0aW1lX3QsIHdlIGRvbid0IGFjY2lkZW50YWxseSBnZXQKYnJva2VuIGludGVyZmFjZXMgKGku ZS4gd2Ugc2hvdWxkIGdldCBhIGNvbXBpbGUgZXJyb3Igd2hlbmV2ZXIgd2UKY2FuJ3QgZ2V0IGl0 IHJpZ2h0IGF1dG9tYXRpY2FsbHkpLgoKT25lIGFzcGVjdCB0aGF0IG1ha2VzIHY0bDJfYnVmZmVy IHNwZWNpYWwgaXMgdGhhdCB0aGUgYmluYXJ5IGZvcm1hdAppcyBhbHJlYWR5IGNsZWFuIGZvciB5 MjAzOCAob25jZSBwYXRjaCA0LzcgImV4eW5vczQtaXM6IHVzZSBtb25vdG9uaWMKdGltZXN0YW1w cyBhcyBhZHZlcnRpemVkIiBnZXRzIG1lcmdlZCksIGFuZCB3ZSBvbmx5IG5lZWQgdG8gd29ycnkg YWJvdXQKd2hhdCBoYXBwZW5zIHdoZW4gdXNlciBzcGFjZSBkaXNhZ3JlZXMgYWJvdXQgdGhlIHNp emUgb2YgdGltZXZhbC4KCkxldCBtZSBkZXNjcmliZSB0aGUgb3B0aW9ucyB0aGF0IEkgY2FuIHRo aW5rIG9mIGhlcmU6CgphKSBTaW1pbGFyIHRvIG15IGZpcnN0IGF0dGVtcHQsIGRlZmluZSBhIG5l dyBzdHJ1Y3QgdjRsMl90aW1ldmFsLCBidXQKICAgb25seSB1c2UgaXQgd2hlbiBidWlsZGluZyB3 aXRoIGEgeTIwMzgtYXdhcmUgbGliYywgc28gd2UgZG9uJ3QgYnJlYWsKICAgZXhpc3RpbmcgZW52 aXJvbm1lbnRzOgoKCS8qIHNvbWUgY29tcGlsZS10aW1lIGNvbmRpdGlvbmFsIHRoYXQgd2UgZmly c3QgbmVlZCB0byBhZ3JlZSBvbiB3aXRoIGxpYmMgKi8KCSNpZiBfX0JJVFNfUEVSX1RJTUVfVCA+ IF9fQklUU19QRVJfTE9ORwoJc3RydWN0IHY0bDJfdGltZXZhbCB7IGxvbmcgdHZfc2VjOyBsb25n IHR2X3VzZWM7IH0KCSNlbHNlCgkjZGVmaW5lIHY0bDJfdGltZXZhbCB0aW1ldmFsCgkjZW5kaWYK CiAgIFRoaXMgbWVhbnMgdGhhdCBhbnkgdXNlciBzcGFjZSB0aGF0IGN1cnJlbnRseSBhc3N1bWVz IHRoZSB0aW1lc3RhbXAKICAgbWVtYmVyIHRvIGJlIGEgJ3N0cnVjdCB0aW1ldmFsJyBoYXMgdG8g YmUgY2hhbmdlZCB0byBhY2Nlc3MgdGhlIG1lbWJlcnMKICAgaW5kaXZpZHVhbGx5LCBvciBnZXQg YSBidWlsZCBlcnJvci4KICAgVGhlIF9fQklUU19QRVJfVElNRV9UIHRyaWNrIGhhcyB0byBiZSB1 c2VkIGluIGEgY291cGxlIG9mIG90aGVyIHN1YnN5c3RlbXMKICAgdG9vLCBhcyBzb21lIG9mIHRo ZW0gaGF2ZSBubyBvdGhlciB3YXkgdG8gaWRlbnRpZnkgYW4gaW50ZXJmYWNlCgpiKSBLZWVwIHRo ZSBoZWFkZXIgZmlsZSB1bmNoYW5nZWQsIGJ1dCBkZWFsIHdpdGggYm90aCBmb3JtYXRzIG9mIHY0 bDJfYnVmZmVyCiAgIGluIHRoZSBrZXJuZWwuIEZvcnR1bmF0ZWx5LCBhbGwgaW9jdGxzIHRoYXQg cGFzcyBhIHY0bDJfYnVmZmVyIGhhdmUKICAgcHJvcGVybHkgZGVmaW5lZCBjb21tYW5kIGNvZGVz LCBhbmQgaXQgZG9lcyBub3QgZ2V0IHBhc3NlZCB1c2luZyBhCiAgIHJlYWQvd3JpdGUgc3R5bGUg aW50ZXJmYWNlLiBUaGlzIG1lYW5zIHdlIG1vdmUgdGhlIHY0bDJfYnVmZmVyMzIKICAgaGFuZGxp bmcgZnJvbSB2NGwyLWNvbXBhdC1pb2N0bDMyLmMgdG8gdjRsMi1pb2N0bC5jIGFuZCBhZGQgYW4g aW4ta2VybmVsCiAgIHY0bDJfYnVmZmVyNjQgdGhhdCBtYXRjaGVzIHRoZSA2NC1iaXQgdmFyaWFu dCBvZiB2NGwyX2J1ZmZlci4KICAgVGhpcyB3YXksIHVzZXIgc3BhY2UgY2FuIHVzZSBlaXRoZXIg ZGVmaW5pdGlvbiBvZiB0aW1lX3QsIGFuZCB0aGUKICAga2VybmVsIHdpbGwganVzdCBoYW5kbGUg dGhlbSBuYXRpdmVseS4KICAgVGhpcyBpcyBnb2luZyB0byBiZSB0aGUgbW9zdCBjb21tb24gd2F5 IHRvIGhhbmRsZSB5MjAzOCBjb21wYXRpYmlsaXR5CiAgIGluIGRldmljZSBkcml2ZXJzLCBhbmQg aXQgaGFzIHRoZSBhZGRpdGlvbmFsIGFkdmFudGFnZSBvZiBzaW1wbGlmeWluZwogICB0aGUgY29t cGF0IHBhdGguCgpjKSBBcyB5b3UgZGVzY3JpYmUgYWJvdmUsIGludHJvZHVjZSBhIG5ldyB2NGwy X2J1ZmZlciByZXBsYWNlbWVudCB3aXRoCiAgIGEgZGlmZmVyZW50IGxheW91dCB0aGF0IGRvZXMg bm90IHJlZmVyZW5jZSB0aW1ldmFsLiBGb3IgdGhpcyBjYXNlLCBJCiAgIHdvdWxkIHJlY29tbWVu ZCB1c2luZyBhIHNpbmdsZSA2NC1iaXQgbmFub3NlY29uZCB0aW1lc3RhbXAgdGhhdCBjYW4KICAg YmUgZ2VuZXJhdGVkIHVzaW5nIGt0aW1lX2dldF9ucygpLgogICBIb3dldmVyLCB0byBhdm9pZCBh bWJpZ3VpdHkgd2l0aCB0aGUgdXNlciBzcGFjZSBkZWZpbml0aW9uIG9mIHN0cnVjdAogICB0aW1l dmFsLCB3ZSBzdGlsbCBoYXZlIHRvIGhpZGUgdGhlIGV4aXN0aW5nICdzdHJ1Y3QgdjRsMl9idWZm ZXInIGZyb20KICAgeTIwMzgtYXdhcmUgdXNlciBzcGFjZSBieSBlbmNsb3NpbmcgaXQgaW4gJyNp ZiBfX0JJVFNfUEVSX1RJTUVfVCA+IAogICBfX0JJVFNfUEVSX0xPTkcnIG9yIHNpbWlsYXIuCgoJ QXJuZApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpZMjAz OCBtYWlsaW5nIGxpc3QKWTIwMzhAbGlzdHMubGluYXJvLm9yZwpodHRwczovL2xpc3RzLmxpbmFy by5vcmcvbWFpbG1hbi9saXN0aW5mby95MjAzOAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.kundenserver.de ([212.227.126.131]:56009 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797AbbIOU0h (ORCPT ); Tue, 15 Sep 2015 16:26:37 -0400 From: Arnd Bergmann To: Hans Verkuil Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, y2038@lists.linaro.org, Mauro Carvalho Chehab , linux-api@vger.kernel.org, linux-samsung-soc@vger.kernel.org Subject: Re: [PATCH 6/7] [RFC] [media]: v4l2: introduce v4l2_timeval Date: Tue, 15 Sep 2015 22:26:23 +0200 Message-ID: <2432018.5rA5LXfiBo@wuerfel> In-Reply-To: <55F846E7.2040006@xs4all.nl> References: <1442332148-488079-1-git-send-email-arnd@arndb.de> <1442332148-488079-7-git-send-email-arnd@arndb.de> <55F846E7.2040006@xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org List-ID: On Tuesday 15 September 2015 18:27:19 Hans Verkuil wrote: > On 09/15/2015 05:49 PM, Arnd Bergmann wrote: > > The v4l2 API uses a 'struct timeval' to communicate time stamps to user > > space. This is broken on 32-bit architectures as soon as we have a C library > > that defines time_t as 64 bit, which then changes the structure layout of > > struct v4l2_buffer. > > > > Fortunately, almost all v4l2 drivers use monotonic timestamps and call > > v4l2_get_timestamp(), which means they don't also have a y2038 problem. > > This means we can keep using the existing binary layout of the structure > > and do not need to worry about defining a new kernel interface for > > userland with 64-bit time_t. > > > > A possible downside of this approach is that it breaks any user space > > that tries to assign the timeval structure returned from the kernel > > to another timeval, or to pass a pointer to it into a function that > > expects a timeval. Those will cause a build-time warning or error > > that can be fixed up in a backwards compatible way. > > > > The alternative to this patch is to leave the structure using > > 'struct timeval', but then we have to rework the kernel to let > > it handle both 32-bit and 64-bit time_t for 32-bit user space > > processes. > > Cool. Only this morning I was thinking about what would be needed in v4l2 > to be y2038 safe, and here it is! Nice! fwiw, I also have a list of drivers at https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit?usp=sharing which lists all known files that still need changing, in case you are wondering what else needs to be done, though it currently only covers things that nobody so far has started working on, and I have a couple patches on my disk that need polishing (I pushed out the v4l2 portion of that as a start) > > @@ -839,7 +845,7 @@ struct v4l2_buffer { > > __u32 bytesused; > > __u32 flags; > > __u32 field; > > - struct timeval timestamp; > > + struct v4l2_timeval timestamp; > > struct v4l2_timecode timecode; > > __u32 sequence; > > > > > > I suspect that quite a few apps use assign the timestamp to another timeval > struct. A quick grep in v4l-utils (which we maintain) shows at least two of > those assignments. Ditto for xawtv3. Ok, that is very helpful information, thanks for finding that! > So I don't think v4l2_timeval is an option as it would break userspace too badly. Agreed, we definitely don't want to break building user space with existing environments, i.e. 64-bit architectures, or 32-bit architectures with 32-bit time_t. > An alternative to supporting a 64-bit timeval for 32-bit userspace is to make a > new y2038-aware struct and a new set of ioctls and use this opportunity to clean > up and extend the v4l2_buffer struct. > > So any 32-bit app that needs to be y2038 compliant would just use the new > struct and ioctls. > > But this is something to discuss among the v4l2 developers. Ok. We generally to require as few source level changes to user space as possible for the conversion, and we want to make sure that when using a 32-bit libc with 64-bit time_t, we don't accidentally get broken interfaces (i.e. we should get a compile error whenever we can't get it right automatically). One aspect that makes v4l2_buffer special is that the binary format is already clean for y2038 (once patch 4/7 "exynos4-is: use monotonic timestamps as advertized" gets merged), and we only need to worry about what happens when user space disagrees about the size of timeval. Let me describe the options that I can think of here: a) Similar to my first attempt, define a new struct v4l2_timeval, but only use it when building with a y2038-aware libc, so we don't break existing environments: /* some compile-time conditional that we first need to agree on with libc */ #if __BITS_PER_TIME_T > __BITS_PER_LONG struct v4l2_timeval { long tv_sec; long tv_usec; } #else #define v4l2_timeval timeval #endif This means that any user space that currently assumes the timestamp member to be a 'struct timeval' has to be changed to access the members individually, or get a build error. The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems too, as some of them have no other way to identify an interface b) Keep the header file unchanged, but deal with both formats of v4l2_buffer in the kernel. Fortunately, all ioctls that pass a v4l2_buffer have properly defined command codes, and it does not get passed using a read/write style interface. This means we move the v4l2_buffer32 handling from v4l2-compat-ioctl32.c to v4l2-ioctl.c and add an in-kernel v4l2_buffer64 that matches the 64-bit variant of v4l2_buffer. This way, user space can use either definition of time_t, and the kernel will just handle them natively. This is going to be the most common way to handle y2038 compatibility in device drivers, and it has the additional advantage of simplifying the compat path. c) As you describe above, introduce a new v4l2_buffer replacement with a different layout that does not reference timeval. For this case, I would recommend using a single 64-bit nanosecond timestamp that can be generated using ktime_get_ns(). However, to avoid ambiguity with the user space definition of struct timeval, we still have to hide the existing 'struct v4l2_buffer' from y2038-aware user space by enclosing it in '#if __BITS_PER_TIME_T > __BITS_PER_LONG' or similar. Arnd