[Xorg-driver-geode] FreeBSD patch for xf86-video-geode 2.11.12

[Mart Raudsepp]

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 <memsize at videotron.ca>:
> > > 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.
> > >
> > > http://www.openbsd.org/i386.html#hardware
> > >
> > > Geode listed as being supported.
> > >
> > > http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-geode/
> > >
> > > 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 http://linux.die.net/man/3/lseek64. 
> 
> 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.


Best,
Mart Raudsepp

> It looks like you have found more porting issues, I'd be surprised if
> there were only one.
> 
> > Martin-Éric
>