Messages in this thread | | | Date | Thu, 22 May 2014 08:30:04 +0900 (JST) | From | Thomas Gleixner <> | Subject | Re: [patch 3/3] timerfd: Implement write method |
| |
On Thu, 22 May 2014, Cyrill Gorcunov wrote: > On Thu, May 22, 2014 at 07:12:30AM +0900, Thomas Gleixner wrote: > > > > There is a world outside of checkpoint/restore, really. > > Yes, I simply don't know who else might use this write() > functionality for other purpose, I mean i don't see a > point to use it for anything else. > > > So what's the semantics of that write function? We really want to have > > that agreed on and documented in the man page. > > The idea was to provide a way to setup @ticks into (nonzero) value > which we get from show_fdinfo output. Then when we restore it > we setup the timer and set @ticks to the value it had at dump > moment.
That's not describing the semantics. It's describing what you use it for.
> > Right now the write will just update the ticks and nothing else. So > > what if there is a waiter already? What if there is a timer armed? > > > > Can you please describe how checkpoint/restore is going to use all of > > this. How is the timer restored and how/when is the reader which was > > waiting in read/poll at the time of suspend reattached to it. > > Thomas, I see what you mean. Need to think (I must admit I forgot about > polling of timerfds :( I were to restore timerfds like this > > - fetch data from fdinfo > - use timer_create/settime to arm it > - write @ticks then
That's clear to me.
So again you have to answer the questions:
Do we just allow the write unconditionally? Do we care about waking readers/pollers?
Whatever the answer is, it needs to be documented coherently in the changelog, in the code and in the man page.
Thanks,
tglx
| |