> > [Was: Re: [PATCH] Revised timerfd() interface]
> >
> > > Michael, could you please refresh our memories with a brief,
> > > from-scratch summary of what the current interface is, followed
> > > by a summary of what you believe to be the shortcomings to be?
> >
> > Andrew,
> >
> > I'll break this up into parts:
> >
> > 1. the existing timerfd interface
> > 2. timerfd limitations
> > 3. possible solutions
> > a) Add an argument
> > b) Create an interface similar to POSIX timers
> > c) Integrate timerfd with POSIX timers
> >
> > Cheers,
> >
> > Michael
> >
> >
> > 1: the existing timerfd interface
> > =================================
> >
> > In 2.6.22, Davide added timerfd() with the following interface:
> >
> > returned_fd = timerfd(int fd, int clockid, int flags,
> > struct itimerspec *utimer);
> >
> > If fd is -1, a new timer is created and started. The syscall
> > returns a file descriptor for the timer. 'utimer' specifies
> > the initial expiration and interval of the timer.
> > 'clockid' is CLOCK_REALTIME or CLOCK_REALTIME. The 'utimer'
> > value is relative, unless TFD_TIMER_ABSTIME is specified in
> > 'flags', in which case the initial expiration is specified
> > absolutely.
> >
> > If 'fd' is not -1, then the call modifies the existing timer
> > referred to by the file descriptor 'fd'. The 'clockid', 'flags',
> > and 'utimer' can all be modified. The return value is 'fd'.
> >
> > The key feature of timerfd() is that the caller can use
> > select/poll/epoll to wait on traditional file descriptors and
> > one or more timers.
> >
> > read() from a timerfd file descriptor (should) return a 4-byte
> > integer that is the number of timer expirations since the last
> > read. (If no expiration has so far occurred, read() will block.)
> >
> > IMPORTANT POINT: as implemented in 2.6.22, timerfd was broken:
> > only a single byte of info was returned by read(). I regard
> > this as a virtue: it gives us something closer to a blank slate
> > for fixing the problems described below; furthermore,
> > arguably at this point we could buy ourselves time by
> > pulling timerfd() from 2.6.23, and taking more time to get
> > things right in 2.6.24.
> >
> > (More details on timerfd() can be found here:
> > http://lwn.net/Articles/245533/)
>
> OK.
>
> > 2. timerfd limitations
> > ======================
> >
> > Unix has two older timer interfaces:
> >
> > * setitimer/getitimer and
> >
> > * POSIX timers (timer_create/timer_settime/timer_gettime).
> >
> > timerfd() lacks two features that are present in the older
> > interfaces:
> >
> > * Retrieve the previous setting of an existing timer when
> > setting a new value for the timer.
> >
> > * Non-destructively fetch the timer remaining until the
> > next expiration of the timer.
> >
> > The fact that this functionality is present in both older APIs
> > strongly suggests that various applications really need both
> > functionalities.
>
> Yes, I can imagine applications wanting to do those things.
>
> > (Davide has argued that timerfd() doesn't need the
> > get-while-setting functionality because we can create multiple
> > timerfd timers. However, POSIX timers also allow multiple
> > timer instances, but nevertheless provide get-while-setting.
> > I would estimate that this functionality would be useful for
> > libraries that want to create and control a (single) timerfd
> > file descriptor that is returned to the caller.)
>
> Sure. If you're implementing a timeout and you want to reset it, you
> might indeed want to know how close the old one was to expiring.
>
> Davide's proposal sounds like an awkward workaround for missing
> functionality.
In the other thread I commented that the userspace solution
starts to look pretty complex, and I doubt that it can
be made to work in all cases.
> Does Davide have a proposal for the non-destructive fetch?
I don't think so, since he disagrees about it's necessity.
> > 3. possible solutions
>
> I don't think we'll have this settled and coded in time for 2.6.23. So I
> think the prudent thing to do is to push this back to 2.6.24 and not
> offer sys_timerfd() in 2.6.23.
I think this would be wise. I'd like to talk with Davide some
more about the possibilities.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages ,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
