<!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 Tue, 2011-11-15 at 10:27 +0200, Martin-Éric Racine wrote: <BLOCKQUOTE TYPE=CITE> <PRE> Gaetan, Thanks for this patch. I'm really wondering whether _LARGEFILE64_SOURCE was intentionally defined or not i.e. do the Durango and MSR codes require explicit 64-bit support or not. IIRC there were similar defines in the Cimarron code as well. Let's see what the AMD guys have to say. </PRE> </BLOCKQUOTE> It'd be nice to know if the geode really needs large file descriptor indeed. If not, we simply remove AC_SYS_LARGEFILE from the path and we are done. I scanned 50 xorg video drivers and found only one (ati) with AC_SYS_LARGEFILE but I don't think it uses any transitional extension xxx64 functions. Only a hand full of xorg modules out of 240 uses large file support. I doubt the code can handle large file support as it seems to me that it is "hard coded" for 32 bit. <BLOCKQUOTE> <PRE> GeodeReadMSR(unsigned long addr, unsigned long *lo, unsigned long *hi) {     unsigned int data[2];     int fd = _msr_open();     int ret;     if (fd == -1) return -1;     ret = lseek(fd, (off_t) addr, SEEK_SET); [...] </PRE> </BLOCKQUOTE> It is casting an unsigned long type (32 bit) to an off_t type (which could be 64 bit). It also does not check for an overflow condition which it should do when supporting 64 bit seek operations on a 32 bit system. I am no expert in this area. <BLOCKQUOTE TYPE=CITE> <PRE> Basically, if this clears ok with them, the only thing we'd need in addition to this to support arbitrary ports would be conditionaly enabling compilation of the z4l.c driver upon detection of the header's presence. Martin-Éric 2011/11/14 Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>>: > The "transitional extension" API is deprecated and is not available on FreeBSD. > It gets replaced with defining _FILE_OFFSET_BITS. > <A HREF="http://www.unix.org/version2/whatsnew/lfs20mar.html#3.0">http://www.unix.org/version2/whatsnew/lfs20mar.html#3.0</A> > > _LARGEFILE64_SOURCE >          Expose definitions for the alternative API specified by the LFS (Large >          File Summit) as a "transitional extension" to the Single UNIX >          Specification.  (See <A HREF="http://opengroup.org/platform/lfs.html">http://opengroup.org/platform/lfs.html</A>.)  The >          alternative API consists of a set of new objects (i.e., functions and >          types) whose names are suffixed with "64" (e.g., off64_t versus off_t, >          lseek64() versus lseek(), etc.).  New programs should not employ this >          interface; instead _FILE_OFFSET_BITS=64 should be employed. > > _FILE_OFFSET_BITS >          Defining this macro with the value 64 automatically converts references >          to 32-bit functions and data types related to file I/O and file system >          operations into references to their 64-bit counterparts.  This is >          useful for performing I/O on large files (> 2 Gigabytes) on 32-bit >          systems.  (Defining this macro permits correctly written programs to >          use large files with only a recompilation being required.)  64-bit >          systems naturally permit file sizes greater than 2 Gigabytes, and on >          those systems this macro has no effect. > > An example using open(): > ----------------------------------------------------------------------- > int > main (void) > { >  return open (".", O_RDONLY) < 0; > } > > it should compile and run just fine, with either Sun C or GCC.  In the > latter case, the return statement expands via the preprocessor to: > >  return open64 (".", 0) < 0; > > so you don't need to have any instances of open64 in your code. > ------------------------------------------------------------------------- > > The file _FILE_OFFSET_BITS macro will be defined by AC_SYS_LARGEFILE > which gets included by the generated config.h. > > This is consistent with all X.Org modules using large file support, > including the server. Recently large file support was added to xorg > app/sessreg which uses lseek. > Only AC_SYS_LARGEFILE was added in sessreg configure.ac. > > It is still unsure if geode driver need support for large file descriptor >2G > > Signed-off-by: Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>> > --- >  configure.ac    |    1 + >  src/durango.c   |    2 -- >  src/geode_msr.c |    9 ++++++--- >  3 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 483caff..31e5fe0 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -30,6 +30,7 @@ AC_INIT([xf86-video-geode], >  AC_CONFIG_SRCDIR([Makefile.am]) >  AM_CONFIG_HEADER([config.h]) >  AC_CONFIG_AUX_DIR(.) > +AC_SYS_LARGEFILE > >  # Require xorg-macros: XORG_DEFAULT_OPTIONS >  m4_ifndef([XORG_MACROS_VERSION], > diff --git a/src/durango.c b/src/durango.c > index 9d6970b..8795d41 100644 > --- a/src/durango.c > +++ b/src/durango.c > @@ -32,8 +32,6 @@ >  #include "config.h" >  #endif > > -#define _LARGEFILE64_SOURCE > - >  #include <unistd.h> >  #include <errno.h> >  #include <compiler.h> > diff --git a/src/geode_msr.c b/src/geode_msr.c > index 6de693f..26fd78f 100644 > --- a/src/geode_msr.c > +++ b/src/geode_msr.c > @@ -1,4 +1,7 @@ > -#define _LARGEFILE64_SOURCE > +#ifdef HAVE_CONFIG_H > +#include "config.h" > +#endif > + >  #include <stdio.h> >  #include <unistd.h> >  #include <fcntl.h> > @@ -31,7 +34,7 @@ GeodeReadMSR(unsigned long addr, unsigned long *lo, unsigned long *hi) >     if (fd == -1) >        return -1; > > -    ret = lseek64(fd, (off64_t) addr, SEEK_SET); > +    ret = lseek(fd, (off_t) addr, SEEK_SET); > >     if (ret == -1) >        return -1; > @@ -56,7 +59,7 @@ GeodeWriteMSR(unsigned long addr, unsigned long lo, unsigned long hi) >     if (fd == -1) >        return -1; > > -    if (lseek64(fd, (off64_t) addr, SEEK_SET) == -1) > +    if (lseek(fd, (off_t) addr, SEEK_SET) == -1) >        return -1; > >     data[0] = lo; > -- > 1.7.4.1 > > _______________________________________________ > Xorg-driver-geode mailing list > <A HREF="mailto:Xorg-driver-geode@lists.x.org">Xorg-driver-geode@lists.x.org</A> > <A HREF="http://lists.x.org/mailman/listinfo/xorg-driver-geode">http://lists.x.org/mailman/listinfo/xorg-driver-geode</A> > </PRE> </BLOCKQUOTE> </BODY> </HTML>