<!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 Sun, 2011-11-13 at 18:45 +0200, Martin-Éric Racine wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 2011/11/13 Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>>: > On Sun, 2011-11-13 at 16:09 +0200, Martin-Éric Racine wrote: > > 2011/11/13 Mart Raudsepp <<A HREF="mailto:leio@gentoo.org">leio@gentoo.org</A>>: >> 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. </PRE> </BLOCKQUOTE> I don't fully understand, but the issue is explained here: <A HREF="http://freecode.com/articles/largefile-support-problems">http://freecode.com/articles/largefile-support-problems</A> 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! <BLOCKQUOTE TYPE=CITE> <PRE> > >> 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 </PRE> </BLOCKQUOTE> </BODY> </HTML>