Re: [UPDATE PATCH] push rounding up of relative request to schedule_timeout()
From: George Anzinger
Date: Wed Aug 17 2005 - 14:51:46 EST
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@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/