From owner-freebsd-current@FreeBSD.ORG Wed Oct 8 06:22:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7681A106568E for ; Wed, 8 Oct 2008 06:22:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D882B8FC25 for ; Wed, 8 Oct 2008 06:22:07 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uUmtgKHQwvA07F2yBopI6A==:17 a=rAaZKoOGbiiHWbGSHA0A:9 a=H3lqEyebxMUFX65LxNMA:7 a=oMODqtlWI_SHHOdSRS9kp2QHvjgA:4 a=LY0hPdMaydYA:10 Received: from [62.113.135.118] (account mc467741@c2i.net [62.113.135.118] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1104083561; Wed, 08 Oct 2008 08:22:04 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 8 Oct 2008 08:24:01 +0200 User-Agent: KMail/1.9.7 References: <200705191730.06964.hselasky@c2i.net> <200705192324.34663.hselasky@c2i.net> <20070519144256.A41946@xorpc.icir.org> In-Reply-To: <20070519144256.A41946@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810080824.01507.hselasky@c2i.net> Cc: Luigi Rizzo Subject: Re: Video4Linux header files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 06:22:08 -0000 On Saturday 19 May 2007, Luigi Rizzo wrote: > On Sat, May 19, 2007 at 11:24:34PM +0200, Hans Petter Selasky wrote: > > On Saturday 19 May 2007 21:14, Luigi Rizzo wrote: > > ... > > > > - i don't know how problematic is this, but v4l2 headers seem to use > > > unnamed unions which, last time i tried, conflict with the compiler > > > setting used to build the kernel. While this is possibly an > > > orthogonal problem which we may have to address at some point (as > > > unnamed unions seem to be a common paradigm in linux headers), it is > > > yet another hurdle. > > > > Unnamed unions are not so good. I suggest that we terminate unnamed > > unions with an "u". We can make this a compile time option: #ifdef NOT_GCC_4X #define MY_UNION u #else #define MY_UNION #endif union { } MY_UNION; I see no problem about that. Else it will be a nightmare to port the code to other and especially older compilers. > > It is not our choice. Linux v4l2 headers use these unions, > software is written against these headers, we can't change the > names unless we want to make extensive changes to the sources. We can be compatible with both! > > > > I suppose a suitable plan would be the following, but i have not had > > > the time to work on it: > > > > > > 1. add a v4lcompat build-dependency on the ports potentially affected, > > > making sure they still build correctly using v4l1 > > > 2. add v4l1 headers in the base system (possibly changing the v4lcompat > > > port to not install the headers if they are already in the base > > > system); > > > > I want to put a V4L2.0 "videodev.h" under /usr/src/sys/sys/ with some > > modifications. What do you think about that? > > All the constraints i mentioned in the original email still apply. > First you need to address the unnamed unions problem, then > you will have to deal with a significant amount of breakage in > the ports. See comment above. > > > > 3. modify the vl4compat port to add the v4l2 headers, again fixing > > > any breakage in the builds > > > 4. as in step 2, add the v4l2 headers to the system, changing v4lcompat > > > as needed where the v4l* headers are in the base OS > > > > Does anyone know which ports use the current Linux compat layer port and > > the v4lcompat port ? > > There is some magic port script you can run on the ports tree to get the > list of ports which depend on v4lcompat. But the problem, as i tried to > explain in the original message, is that there are ports which don't have a > v4lcompat dependency while they should (at least to have a > consistent build environment) and others which misbehave when they find > a v4l header. --HPS