Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750806AbVJQQoI (ORCPT ); Mon, 17 Oct 2005 12:44:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750808AbVJQQoI (ORCPT ); Mon, 17 Oct 2005 12:44:08 -0400 Received: from mail-red.bigfish.com ([216.148.222.61]:20007 "EHLO mail39-red-R.bigfish.com") by vger.kernel.org with ESMTP id S1750806AbVJQQoG (ORCPT ); Mon, 17 Oct 2005 12:44:06 -0400 X-BigFish: V Message-ID: <4353D60E.70901@am.sony.com> Date: Mon, 17 Oct 2005 09:49:18 -0700 From: Tim Bird User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roman Zippel CC: Andrew Morton , Ingo Molnar , tglx@linutronix.de, george@mvista.com, linux-kernel@vger.kernel.org, johnstul@us.ibm.com, paulmck@us.ibm.com, hch@infradead.org, oleg@tv-sign.ru Subject: Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5 References: <1128168344.15115.496.camel@tglx.tec.linutronix.de> <1129016558.1728.285.camel@tglx.tec.linutronix.de> <434DA06C.7050801@mvista.com> <1129490809.1728.874.camel@tglx.tec.linutronix.de> <20051017075917.GA4827@elte.hu> <20051017094153.GA9091@elte.hu> <20051017025657.0d2d09cc.akpm@osdl.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3087 Lines: 71 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/