SVID functions used in bb

[Rob Landley]

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();

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.

> 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
-- 
Never bet against the cheap plastic solution.