On Sun, 2011-11-13 at 18:45 +0200, Martin-Éric Racine wrote: > 2011/11/13 Gaetan Nadon <mems...@videotron.ca>: > > On Sun, 2011-11-13 at 16:09 +0200, Martin-Éric Racine wrote: > > > > 2011/11/13 Mart Raudsepp <l...@gentoo.org>: > >> I don't have any particular idea about the FreeBSD side of things (does > >> BSD really not have separate 64bit largefile offset handling routines?). > > > > Apparently not. 64-bit variants of everything seem to be defined via > > sys/types.h, but neither lseek or off_t seem to have any defined.
I don't fully understand, but the issue is explained here: http://freecode.com/articles/largefile-support-problems FreeBSD has dropped 32bit support unlike Linux. So off_t is always 64 bit. Who ever wants to port the code to FreeBSD should look at the X server code which runs on several platforms. It does not use lseek64 or off64_t. It does use AC_SYS_LARGEFILE in configure.ac which provides some support that I don't really understand. It will probably affect the z4l.c file as well. So what we did with __FreeBSD__ is just plain wrong. One question that pops to my mind is what happens to the 32 bit AMD assembler code in durango.c? I recall seeing places where the code makes assumptions that the size is 32 when it turns out to be 64 on AMD64. I think there will be some 32/64 sanitizing done. Perhaps a good place to start would be to get a clean compile on AMD64. I am assuming here that FreeBSD is a 64 bit OS. I don't have real answers, just raising relevant questions! > > > >> But seeing as all this patch really does, is disable z4l code if host is > >> bsd, then we could very easily go one step further and provide a > >> AC_ARG_ENABLE or AC_ARG_WITH (whichever is more appropriate here) option > > > > I was going to propose that next. Even if it "can be built", it does not > > "have to be built". So --enable-z4l (or ztv if more descriptive) would be > > added on the command line for system builders who do wish to have this > > feature. Based on your comments, it looks like it would be disabled by > > default. > > Please note that the 64-bit function equivalents are needed to compile > the Geode driver on FreeBSD, regardless of whether ztv is included or > not. At this much I understood from Arrigo's mail, last time he tried > submitting a patch. > > > Unrelated here, just my opinion. Having done a bit of googling, it looks > > like there are more OS or linux flavors where Geode is used. I saw this > > board used in the industry as an embedded PC. I noticed Gentoo builds on > > Geode. More users is always good. That means writing more portable code and > > revisiting some assumptions. > > It has mostly been used on Linux, but there was demand also on the BSD > side. AFAIK they got around implementing platform device support in > their kernels, but I never heard of any patch for the X driver. > > 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