[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0707171501420.26781@alien.or.mcafeemobile.com>
Date: Tue, 17 Jul 2007 15:06:01 -0700 (PDT)
From: Davide Libenzi <davidel@...ilserver.org>
To: Michael Kerrisk <mtk-manpages@....net>
cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
akpm@...l.org
Subject: Re: timerfd(2) draft man page plus questions
On Tue, 17 Jul 2007, Michael Kerrisk wrote:
> > > 1. timer_settime() and setitimer() both permit the caller to obtain
> > > the old value of the timer when modifying an existing timer. Why
> > > doesn't timerfd() provide this functionality?
> >
> > I don't know ;) Would it be any useful?
>
> Well given that the two older APIs both provide this
> functionality, it seems that it is desired in applications. It
> is a shame that the new API doesn't have this. It could be
> added (I'm inclined to say, it should be): the only problem
> is that the syscall is now out in the wild, so a change at
> this point would not be ABI compatible. However, it only just
> got into the wild (and hasn't made it into glibc yet), so now
> would be a good time to fix it, if you are agreeable, and the
> kernel gatekeepers are prepared to tolerate the ABI change.
But the old status of the timer is the union of clickid, flags and utmr.
So, in theory, the whole set should be returned back, forcing a pretty
drastic API change.
IMHO, given that is not really clear what the real advantages would be in
the API change, I'd rather prefer to leave the current one.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists