On Mon, 2011-11-14 at 07:47 +0200, Mart Raudsepp wrote: > 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 <mems...@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. >
geode_msr.c defines LARGEFILE64_SOURCE http://linux.die.net/man/3/lseek64 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? > > Best, > Mart Raudsepp > > > It looks like you have found more porting issues, I'd be surprised if > > there were only one. > > > > > Martin-Éric > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xorg-driver-geode mailing list Xorg-driver-geode@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-geode