Do we need sys_open() et al (_LARGEFILE64_SOURCE and open64())?

Andrew Bartlett abartlet at samba.org
Sat Mar 24 20:55:04 MDT 2012


On Sat, 2012-03-24 at 07:11 -0700, Jeremy Allison wrote:
> On Sat, Mar 24, 2012 at 02:58:19PM +0100, Volker Lendecke wrote:
> > On Sat, Mar 24, 2012 at 02:43:15PM +0100, Jelmer Vernooij wrote:
> > > At the moment we have two trivial wrappers for fork() and getpid() in
> > > lib/util/system.c. These wrappers exist so that we can cache the PID and
> > > avoid a system call when getpid() is called.
> > > 
> > > Is this optimization actually still worth the trouble these days? We
> > > don't seem to have any regularly called code paths that need it. The
> > > printing code seems to use it as a simple way of identifying a single
> > > server in the database, but that can be worked around by just using a
> > > single variable there.
> > > 
> > > Furthermore, there is the risk that we end up not updating the pid after
> > > a fork() - thus ending up with sys_getpid() returning the wrong pid. For
> > > example, our libraries are used in various applications, either directly
> > > or as part of e.g. openchange, which don't use sys_fork() but plain fork.
> > > 
> > > Thoughts?
> > 
> > I think that can go. I think at least glibc caches that
> > anyway, and we try to move away from getpid to
> > messaging_server_id() and friends.
> 
> +1 from me also (and I added them originally :-).
> 
> No longer needed - thanks !

While we are thinking about sys_ wrappers, I wondered if we still really
needed the sys_*() wrappers for open64 etc?  

man feature_test_macros(7) says:

       _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 http://opengroup.org/platform/lfs.html.)  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.  

As such, are there any systems that we need that have
_LARGEFILE64_SOURCE but not _FILE_OFFSET_BITS?

Thanks,

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



More information about the samba-technical mailing list