lkml.org 
[lkml]   [2014]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 3/3] timerfd: Implement write method
    On Thu, 22 May 2014, Cyrill Gorcunov wrote:
    > On Thu, May 22, 2014 at 06:43:08AM +0900, Thomas Gleixner wrote:
    > > On Tue, 29 Apr 2014, Cyrill Gorcunov wrote:
    > > > +static ssize_t timerfd_write(struct file *file, const char __user *buf,
    > > > + size_t count, loff_t *ppos)
    > > > +{
    > > > + struct timerfd_ctx *ctx = file->private_data;
    > > > + u64 ticks = 0;
    > > > +
    > > > + if (count < sizeof(ticks))
    > > > + return -EINVAL;
    > > > +
    > > > + if (get_user(ticks, (u64 __user *) buf))
    > > > + return -EFAULT;
    > > > +
    > > > + spin_lock_irq(&ctx->wqh.lock);
    > > > + ctx->ticks = ticks;
    > >
    > > So what wakes a potential waiter in read/poll?
    >
    > Why should it? You mean the scenario when timer is armed then
    > someone writes nonzero @ticks and we should wake waiters?
    > The idea was to setup this ticks on timer restore without
    > waking anyone. If it breaks the logic of timerfd in general,
    > then sure I need to rework. Hm?

    There is a world outside of checkpoint/restore, really.

    So what's the semantics of that write function? We really want to have
    that agreed on and documented in the man page.

    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.

    Thanks,

    tglx


    \
     
     \ /
      Last update: 2014-05-22 02:21    [W:4.744 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site