Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[Tim Bird]

Roman Zippel wrote:
> On Mon, 17 Oct 2005, Andrew Morton wrote:
> > That being said, I'll confess that I've largely ignored this discussion in
> > the hope that things would get sorted out.  Seems that this won't be
> > happening and as Roman's opinions carry weight I do intend to solicit a
> > (brief!) summary of his objections from him when the patch comes round
> > again.  Sorry.
>
>
> 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.

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.)

> - 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.

> - 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.

> Maybe I'm the only one who found Thomas answers a little superficial, but 
> as this is a central kernel subsystem I think it deserves a closer look 
> and everytime I tried to poke a little deeper I got nothing.

No one minds poking deep.  But frankly, I find hypothetical arguments
to be less useful than reality-backed ones.  I would rather not hear
reasoning about a resolution issue - I'd like to numbers, if possible,
about the degradation of performance, if that's the issue.  If
it's confusion about the API, then maybe we just need clear statements
that "X API provides resolution at Y level (from one of: hardware, tick, 
something else).

Regards,
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

-
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/