<!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 07:47 +0200, Mart Raudsepp wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On P, 2011-11-13 at 21:12 -0500, Gaetan Nadon wrote: > On Mon, 2011-11-14 at 03:10 +0200, Martin-Éric Racine wrote: > > 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. > > Of course it does not run on 64bit. Geode video driver is for an integrated into the Geode CPU graphics functionality, and the Geode CPU is a i686 32bit CPU (without some Pentium Pro add-ons to i686 insn), so the code would be never executed on a 64bit OS. > > 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. > > > 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. > ret = lseek64(fd, (off64_t) addr, SEEK_SET); > 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. My understanding is that the primary reason of lseek64 and co existing is for supporting large files/descriptors (larger than 4GB) on 32bit CPUs correctly. That said, I'm not sure how much sense it makes in the context of 32bit CPU MSR registers. Maybe /dev/cpu/0/msr is supposed to be accessed with largefile routines? Or maybe not. </PRE> </BLOCKQUOTE> geode_msr.c defines LARGEFILE64_SOURCE <A HREF="http://linux.die.net/man/3/lseek64">http://linux.die.net/man/3/lseek64</A> If I read the man page correctly, one can use #define _FILE_OFFSET_BITS 64 and lseek/off_t and would work the same way, but in a portable way for FreeBSD as they don't have lseek64 defined. We can thus benefit from AC_SYS_LARGEFILE as the macro will set-up the #define _FILE_OFFSET_BITS 64 on the appropriate platforms, now and in the future. Does anyone know if geode_msr need to use "large" file descriptor? <BLOCKQUOTE TYPE=CITE> <PRE> Best, Mart Raudsepp > It looks like you have found more porting issues, I'd be surprised if > there were only one. > > > Martin-Éric > </PRE> </BLOCKQUOTE> </BODY> </HTML>