Re: API explosion (Re: [RFC/RFT] calloutng)

On 19.12.2012 16:20, Bruce Evans wrote:
> On Wed, 19 Dec 2012, Davide Italiano wrote:
>
>> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans <brde_at_optusnet.com.au>
>> wrote:
>
>>> I would have tried a 32 bit format with a variable named 'ticks'.
>>> Something like:
>>> - ticks >= 0.  Same meaning as now.  No changes in ABIs or APIs to use
>>>   this.  The tick period would be constant but for virtual ticks and
>>>   not too small.  hz = 1000 now makes the period too small, and not a
>>>   power of 2.  So make the period 1/128 second.  This gives a 1.24.7
>>>   binary format.  2**24 seconds is 194 days.
>>> - ticks < 0.  The 31 value bits are now a cookie (descriptor) referring
>>>   to a bintime or whatever.  This case should rarely be used.  I don't
>>>   like it that a tickless kernel, which is needed mainly for power
>>>   saving, has expanded into complications to support short timeouts
>>>   which should rarely be used.
>>
>> Bruce, I don't really agree with this.
>> The data addressed by cookie should be still stored somewhere, and KBI
>> will result broken. This, indeed, is not real problem as long as
>> current calloutng code heavily breaks KBI, but if that was your point,
>> I don't see how your proposed change could help.
>
> In the old API, it is an error to pass ticks < 0, so only broken old
> callers are affected.  Of course, if there are any then it would be
> hard to detect their garbage cookies.
>
> Anywy, it's too later to change to this, and maybe also to a 32.32
> format.

It would be late to change this after committing. I would definitely 
like it to be done earlier to not redo all the tests, but I think we 
could convert callout and eventtimers code to 32.32 format in several 
days. The only two questions are: do we really want it (won't there be 
any reasons to regret about it) and how do we want it to look?

For the first question my personal showstopper since eventtimers 
creation always was the wish to keep consistency. But benefits of 32.32 
format are clear, and if there are more votes for it, let's consider. If 
now it will be decided that full range will never be useful for callout 
subsystem, then it is obviously not needed for eventtimers also.

About the second question, what do you think about such prototypes:

typedef int64_t sbintime_t

static __inline sbintime_t
bintime_shrink(struct bintime *bt)
{}

static __inline struct bintime
bintime_expand(sbintime_t sbt)
{}

...

int
callout_reset_bt(struct callout *, sbintime_t sbt, sbintime_t pr,
	void (*fn)(void *), void *arg, int flags);

, where pr used only for absolute precision, and flags includes: direct 
execution, absolute/relative time in argument, relative precision in 
case of relative sbt, flag for aligning to hardclock() to emulate legacy 
behavior, and potentially flags for reaction on suspend/resume.

Another option is to move absolute precision also to flags, using log2() 
representation, as we tried and as was proposed before. With possibility 
to use precise relative time there will be few cases requiring absolute 
value of precision, that should depend on period. Then there will be no 
extra arguments in the most usual cases.

Wrapper for existing API compatibility will look just like this:

#define callout_reset(c, ticks, fn, arg)		\
     callout_reset_bt(c, ticks2sbintime(ticks), -1,	\
     (fn), (arg), C_HARDCLOCK)

-- 
Alexander Motin