Hi,
On Mon, 17 Oct 2005, Tim Bird wrote:
> > It's rather simple:
> > - "timer API" vs "timeout API": I got absolutely no acknowlegement that this
> > might be a little confusing and in consequence "process timer" may be a
> > better name.
>
> I agree with Thomas on this one. Maybe "timer" and "timeout" are too close,
> but I think they are the most descriptive names.
> - timeout is something used for a timeout. Timeouts only actually
> expire infrequently, so they have a host of attributes associated
> with that characteristic.
> - timer is something used to time something. They almost always
> expire as part of their normal behaviour. In the ktimer code they
> have a host of attributes related to this characteristic.
There is of course a difference, but is it big enough that they deserve
different APIs? Just look into <linux/timer.h> it doesn't mention timeout
once, but according to Thomas that's our "timeout API". Look at the
description of mod_timer() in timer.c: "modify a timer's timeout".
It seems I'm not only one who thinks that both are closely related.
> Thomas answered the suggestion to use "process timer" as an alternative name,
> but I didn't see a reply after that from Roman (I may have missed it.)
It was short and painless:
} > > Calling them "process timer" and "kernel timer" would include their main
} > > usage, although that also means ptimer were the more correct abbreviation.
} >
} > As said before I think the disctinction between timers and timeouts
} > makes perfectly sense and ktimers are _not_ restricted to process
} > timers.
}
} "main usage" != "restricted to"
IOW I didn't say that "process timer" are restricted to processes, but
it's their intended main usage. "kernel timer" are OTOH the first choice
for any internal kernel time issues (which are not just timeouts).
> > - I pointed out various (IMO) unnecessary complexities, which were rather
> > quickly brushed off e.g. with a need for further (not closer specified)
> > cleanups.
>
> This is rather vague. It is rather easy to raise hypothetical
> issues. From what I've seen, Thomas has gone to great lengths to
> address specific issues raised. For example, he actually compiled
> code on 4 different platforms to get the REAL size of the assembly
> fragments, in order to address your concern about CONJECTURED size
> problems.
This was the _only_ issue where he got into any detail, but I also
mentioned later that this one of the minor issues.
Above was about the size of the ktimer structure and interval timer.
> > - resolution handling: at what resolution should/does the kernel work and
> > what do we report to user space. The spec allows multiple interpretations
> > and I have a hard time to get at least one coherent interpretation out of
> > Thomas.
>
> Huh? I thought Thomas' last answer was pretty clear.
Then I must have missed something. Earlier he just quotes something from
SUS without any explanation. His last answer was just about user
expectations without any connection to the different resolutions at the
kernel side I described in the mail before.
bye, Roman
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
