Re: [UPDATE PATCH] push rounding up of relative request to schedule_timeout()

[George Anzinger <george@mvista.com>]

Nishanth Aravamudan wrote:
~
> > IMNSHO we should not get too parental with kernel only interfaces. 
> > Adding 1 is easy enough for the caller and even easier to explain in the 
> > instructions (i.e. this call sleeps for X jiffies edges).  This allows 
> > the caller to do more if needed and, should he ever just want to sync to 
> > the next jiffie he does not have to deal with backing out that +1.
>
>
> I don't want to be too parental either, but I also am trying to avoid
> code duplication. Lots of drivers basically do something like
> poll_event() does (or could do with some changes), i.e. looping a
> constant amount multiple times, checking something every so often. The
> patch was just a thought, though. I will keep evaluating drivers and see
> if it's a useful interface to have eventually.
>
> I guess I'm just concerned with making an unintuitive interface. As was
> brought up at OLS, drivers are a major source of bugs/buggy code. The
> simpler, more useful we can make interfaces, the better, I think. I'm
> not claiming you disagree, I just want to make my own motives clear.
> While fixing up the schedule_timeout() comment would make it clear what
> schedule_timeout() achieves, I'm not sure how useful such an interface
> is, if every caller adds 1 :) I need to mull it over, though... Lots to
> consider. I also, of course, want to stay flexible for the reasons you
> mention (letting the driver adjust the timeout as they expect to).

I would leave the +1 alone and put in the correct documentation.  This 
way _more_ folks will be made aware of the mid jiffie issue.  Far to 
often we see (and let get in) patches that mess up user interfaces 
around this issue.  The recent changes to itimer come to mind...
>
~
--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/