<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2"> </HEAD> <BODY> On Mon, 2011-11-14 at 03:10 +0200, Martin-Éric Racine wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 2011/11/14 Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>>: > On Sun, 2011-11-13 at 23:51 +0200, Martin-Éric Racine wrote: > > It just occured to me that Marc Balmer once contacted the list with an > announce that he was maintaining the OpenBSD port of xf86-video-geode. > Let's see if he can participate in this discussion and provide some of > the answers. Who knows, he might already have a usable diff to provide > us with as a starting point. :) > > > Great. > > <A HREF="http://www.openbsd.org/i386.html#hardware">http://www.openbsd.org/i386.html#hardware</A> > > Geode listed as being supported. > > <A HREF="http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-geode/">http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-geode/</A> > > I could not really see any code changes having been done. Try the diff to these two, for starters: --- xf86-video-geode/src/Makefile.am +++ OpenBSD/xenocara/driver/xf86-video-geode/src/Makefile.am --- xf86-video-geode/src/geode_msr.c +++ OpenBSD/xenocara/driver/xf86-video-geode/src/geode_msr.c There's also some interesting changes to *_driver.c and to lx_exa.c as well. A worrisome number of #ifdef, rather than autoconf/automake/libtool magic, but it's still a nice start. > on OpenBSD/i386 (32 bit) and not 64 bit which would be OpenBSD/amd64 (Intel > EMT64 is considered a clone of AMD64). If I see this correctly, the OpenBSD > geode driver does not run on 64 bit and therefore would not be of a great > help. It does help us see how OpenBSD dealt with the lack of V4L2 capability and with finding the MSR on their platform, among other things. That's a good start for adding BSD support in general. </PRE> </BLOCKQUOTE> I ?think? I have figured out part of it. It is relatively simple. Geode driver should use AC_SYS_LARGEFILE. It's job is to test the size off_t. If 64, it defines #define _FILE_OFFSET_BITS 64 on system where it can be set. With this being set, lseek will become lseek64 and off_t will become off64_t. This behaviour is described in Linux man page <A HREF="http://linux.die.net/man/3/lseek64.">http://linux.die.net/man/3/lseek64.</A> The geode_msr.c code should not hard code lseek64 or off64_t as these are not defined by all OS such as FreeBSD. <BLOCKQUOTE> <PRE> ret = lseek64(fd, (off64_t) addr, SEEK_SET); </PRE> </BLOCKQUOTE> This is what prompted FreeBSD to define lseek64 and off64_t. With this fix, which is trivial to test, FreeBSD will work and so will any platform. Another thought. Perhaps FreeBSD was a 32 bit version (with 64 bit, durango.c would fail). In this case AC_SYS_LARGEFILE is not needed and we just need to replace lseek64 with lseek. Comes to think of it, it's strange to code lseek64 on code that only compiles on 32 bit OS. It looks like you have found more porting issues, I'd be surprised if there were only one. <BLOCKQUOTE TYPE=CITE> <PRE> Martin-Éric </PRE> </BLOCKQUOTE> </BODY> </HTML>