struct timex and Linux adjtimex()

[Poul-Henning Kamp]

--------
Konstantin Belousov writes:
> On Thu, Dec 03, 2020 at 10:26:26AM +0000, Poul-Henning Kamp wrote:
> > --------
> > Konstantin Belousov writes:
> > > On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote:
> > > > --------
> > > > Konstantin Belousov writes:
> > > > 
> > > > > 1. Implement new syscall, which would take extended struct timex.
> > > > >    ntp_adjtimex() perhaps should be kept for backward compatibility.
> > > > >    [It does not matter where struct timeval is placed in the updated
> > > > >    struct timex, see below].
> > > > 
> > > > That would break all ports with timekeeping software.
> > > Why ?
> > 
> > Last I looked they all had "#ifdef FreeBSD use ntp_adjtim()", so if
> > you rename it to ntp_adjtimex() you break them.
> > 
> > I see no problem having a #define to alias timex() to ntp_adjtime(),
> > but I doubt it would make life easier for anybody.  (I think we used
> > to have that and it got GC'ed.)
> > 
> > *If* we want to do this, the right way is to extend struct timex and
> > let ntpadjtime(2) handle the new modes.
>
> I do not propose to rename anything, the new syscall should be called
> ntp_adjtime, as it is now.

Ahh, sorry.  In the first email (quoted above) you wrote "ntp_adjtimex"
and I thought that was deliberate.

In that case, yeah, then your #1 is probably the way to go *IF* we want
to do this.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.