SVID functions used in bb

Peter S. Mazinger ps.m at gmx.net
Thu Mar 30 09:06:40 UTC 2006


On Wed, 29 Mar 2006, Rob Landley wrote:

> On Friday 24 March 2006 4:23 am, Peter S. Mazinger wrote:
> > Hello!
> >
> > Sorry for cross-posting, both lists are affected.
> >
> > I am intending to add an uClibc config option that disables the SVID
> > (System V R4) only functions in uClibc (the common BSD/SVID ones remain
> > untouched for now). These are fgetpwent[_r]/fgetgrent[_r]/putpwent/stime.
> 
> > 3. stime is used by date/rdate
> 
> stime() is a syscall, and it uses a time_t structure.
> 
> The alternative is settimeofday(), which takes two arguments.  The second the 
> man page describes as obsolete and goes on to bitch about at length.  The 
> first is a struct containing a time_t and a microseconds field, which I don't 
> think our date supports anyway.

settimeofday is not mentioned in SuSv3. Haven't checked if all archs have 
stime syscall, if an arch does not have it, then uClibc's stime is 
implemented by using settimeofday.
 
> As far as I can tell, switching from stime() to settimeofday() would bloat 

true if the arch has stime syscall, else no.

> busybox for no readily apparent reason.  Is there some other syscall we 
> should be using that I didn't notice?  Is supporting a non-deprecated linux 
> syscall a big imposition?
> 
> Rob

rdate-1.4 uses stime
hwclock(util-linux) uses settimeofday (earlier it has used stime)
date(coreutils) uses one of settimeofday or stime (in this order)
ntp opts for clock_settime, settimeofday or stime

Only clock_settime is in SuSv3 and is a syscall (or if not available is 
defined using settimeofday in uClibc). 2.4.32 kernels have it only for 
parisc/ppc, 2.6.14 for many (at least all archs being supported by uClibc)

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list