SVID functions used in bb

[Peter S. Mazinger]

On Thu, 30 Mar 2006, Rob Landley wrote:

> On Thursday 30 March 2006 4:06 am, Peter S. Mazinger wrote:
> > 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.
> 
> Neither is mount or init, but they're kind of important.
> 
> > 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.
> 
> In 2.6.16 it's in include/linux/syscalls.h which is not arch specific.
> 
> > > As far as I can tell, switching from stime() to settimeofday() would
> > > bloat
> >
> > true if the arch has stime syscall, else no.
> 
> It would certainly bloat _busybox_ to have to set up a more complicated 
> structure and pass in more arguments for no gain.  Whether it bloats the 
> library we link against is a separate issue.
> 
> So actually looking at how long stime() has been in the linux kernel, I see 
> that it was in 1.0.9:
> 
> http://lxr.linux.no/source/include/linux/sys.h?v=1.0.9
> 
> Which means that any Linux platform that doesn't support it is _less_ capable 
> today than the 1.0 kernel was, which seems unlikely.
> 
> Ok, now I'm curious...  Download linux-0.01, rummage around a bit...
> 
> grep time linux/include/linux/sys.h
> extern int sys_time();
> extern int sys_stime();
> extern int sys_utime();
> extern int sys_ftime();
> extern int sys_times();

haven't known about those, checked grep time asm*/*

> 
> I see stime().  I don't see any of the other alternatives under discussion.  
> You're suggesting the existence of an arch that doesn't have a syscall the 
> 0.01 kernel had?  Are you suggesting that Linux is likely to remove a syscall 
> it has had since 0.01, which is still in use?
> 
> I thought the first 48 or so syscalls were all standardized by posix?
> 
> > > 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)
> 
> Lemme guess:they want to support nanoseconds?
> 
> > date(coreutils) uses one of settimeofday or stime (in this order)
> 
> Ditto.
> 
> > ntp opts for clock_settime, settimeofday or stime
> 
> clock_settime?  (Looks it up...)  Oh dear.  If the purpose of a clock is to 
> tell the correct time, why on _earth_ would you need more than one?  Either 
> you have a correct time, or you don't have a correct time.  Is there an 
> interesting case of more than one correct time?  (What, relativistic 
> effects?)  I'm aware that a PC has a cmos clock and software clock, but you 
> just implied that hwclock wasn't using this.

you need to only lookup in date applet, but rdate will also set the time.

Peter
> 
> > Only clock_settime is in SuSv3
> 
> SuSv3 has pax but not tar or zip.  SuSv3 has sccs but not svn.  This is 
> relevant how?
> 
> > and is a syscall
> 
> Not according to the linux kernel, and not according to the ubuntu man pages.  
> This is a standard that does not match reality.
> 
> > (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)
> 
> And it's not supported on 2.4.  A ringing endorsement...
> 
> > Peter
> 
> Rob
> 

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