xiaoxiang781216 commented on pull request #4193: URL: https://github.com/apache/incubator-nuttx/pull/4193#issuecomment-884369694
> > > > a compiler option turned large file support on or off (selecting the 32-bit or 64-bit APIs) > > > > > > > > > You can see the old uClibc LFS support built in (or not) here: https://git.uclibc.org/uClibc/tree/libc/stdio/Makefile.in#n22 > > > > > > This design is to keep the binary compatibility, it isn't the goal of NuttX. But anyway, I add a new option FS_LARGEFILE which is similar to UCLIBC_HAS_LFS. > > The point is that, at least in the past, LFS worked because on 32-bit platforms libc implemented standard 32-bit versions of file access functions as well as 64-bit versions. If LFS was selected, the compiler mangled the function names so that the application linked to the 64-bit versions. That answers DavidS's question about the naming of the 64-bit file access functions: the application never saw the name of the 64-bit version. > > None of this is now needed with the moden 64-bit desktop CPUs. Yes, but all fs syscall and driver inside linux kernel already switch to 64bit version even on 32bit arch. The only reason that libc keep 32bit version just want to keep the binary compatiblity. If you look at the new libc implementation after LFS become the standard, there is no 32bit version at all regoardless whether the target platform is 32bit or 64bit: https://github.com/bminor/musl/blob/master/include/alltypes.h.in#L29 https://github.com/bminor/musl/blob/master/include/unistd.h#L42 https://github.com/bminor/musl/blob/master/include/unistd.h#L197-L205 musl is a popular libc library and is used on many 32bit embedded platform. Actually, my change reference how musl do the same thing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
