On Thu, May 22, 2014 at 08:30:04AM +0900, Thomas Gleixner wrote: > > > > > 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.
That's I've been intending to use it for and as result the semantic was to write unconditionally. But because I missed polling in first place now I think such semantic is wrong and write() should be a complete counterpart of read() method and wake up waiters. > > > 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. "Yes" to both questions I think. Thomas I'll return with a new patchset, testcase and man update. -- 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/
