I noticed that chipset_enable.c has #define _LARGEFILE64_SOURCE but it does not perform any open/seek, whereas other files (especially physmap.c) have no indication of large file support, yet they do use open/seek. Looking at the code history this seems to be an accident.
What's the correct way to get large file support, and do we need it at all? Image files will probably stay smaller than 16 MB, so I see no real problems there, but MSR support and physmap support may need this.
Regards, Carl-Daniel
On 04.10.2010 14:20, Carl-Daniel Hailfinger wrote:
I noticed that chipset_enable.c has #define _LARGEFILE64_SOURCE but it does not perform any open/seek, whereas other files (especially physmap.c) have no indication of large file support, yet they do use open/seek. Looking at the code history this seems to be an accident.
What's the correct way to get large file support, and do we need it at all? Image files will probably stay smaller than 16 MB, so I see no real problems there, but MSR support and physmap support may need this.
Segher said the following compiler flags work for him: -DLARGE_FILES -D_FILE_OFFSET_BITS=64
On the net I also found the following: -D_LARGE_FILES -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
Regards, Carl-Daniel
On 04/10/10 13:30, Carl-Daniel Hailfinger wrote:
On 04.10.2010 14:20, Carl-Daniel Hailfinger wrote:
I noticed that chipset_enable.c has #define _LARGEFILE64_SOURCE but it does not perform any open/seek, whereas other files (especially physmap.c) have no indication of large file support, yet they do use open/seek. Looking at the code history this seems to be an accident.
What's the correct way to get large file support, and do we need it at all? Image files will probably stay smaller than 16 MB, so I see no real problems there, but MSR support and physmap support may need this.
Segher said the following compiler flags work for him: -DLARGE_FILES -D_FILE_OFFSET_BITS=64
-D_FILE_OFFSET_BITS=64 is all you should need. _LARGEFILE_SOURCE should only be needed when using fseeko on glibc-2.2, or when you explicitly use open64() etc.
For maximum portability see AC_SYS_LARGEFILE from autoconf
cheers, Pádraig.
On 04/10/10 13:20, Carl-Daniel Hailfinger wrote:
I noticed that chipset_enable.c has #define _LARGEFILE64_SOURCE but it does not perform any open/seek, whereas other files (especially physmap.c) have no indication of large file support, yet they do use open/seek. Looking at the code history this seems to be an accident.
What's the correct way to get large file support, and do we need it at all? Image files will probably stay smaller than 16 MB, so I see no real problems there, but MSR support and physmap support may need this.
Heh, on a related note, I noticed that if I put this at the top of physmap.c it works around the signed shift error in the mmap syscall I previously mentioned: #define _FILE_OFFSET_BITS 64 Following is a minimal producer.
/* removing the following define breaks some 32 bit fedora 12/13 systems. */ #define _FILE_OFFSET_BITS 64 #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>
int main (void) { int fd_mem = open("/dev/mem", O_RDWR | O_SYNC); if (fd_mem == -1) { fprintf (stderr, "error opening /dev/mem [%m]\n"); exit (1); } unsigned long addr = 0xfff80000; size_t len = 0x80000; void *virt_addr = mmap(0, len, PROT_WRITE | PROT_READ, MAP_SHARED, fd_mem, (off_t)addr); if (virt_addr == MAP_FAILED) { fprintf (stderr, "error mmaping /dev/mem (addr=%08lX, size=%zu) [%m]\n", addr, len); exit (1); } exit (0); }
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [101004 14:20]:
I noticed that chipset_enable.c has #define _LARGEFILE64_SOURCE but it does not perform any open/seek, whereas other files (especially physmap.c) have no indication of large file support, yet they do use open/seek. Looking at the code history this seems to be an accident.
Yes it should be moved to physmap.c
What's the correct way to get large file support, and do we need it at all? Image files will probably stay smaller than 16 MB, so I see no real problems there, but MSR support and physmap support may need this.
AFAICT it's not about the images, but I think it could be helpful when mmapping areas of /dev/mem.
Stefan