Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp837336ybk; Wed, 13 May 2020 14:36:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlNzKvWKnUrC5MONtZ0tYSjQ9YG8QeNXCP79lA4bSwBIT4wlGceVJmpsAgGLvmrfcKFqGZ X-Received: by 2002:a17:906:cd18:: with SMTP id oz24mr1026792ejb.179.1589405784616; Wed, 13 May 2020 14:36:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589405784; cv=none; d=google.com; s=arc-20160816; b=DdTsTTFhTi0TapK5qbYxz0ouZ00mzUQpaV17dukkM+fWRtpsrtPPh5pEg/RlrUtxsj gHpQnrBIYLzsKr7DxiYAsc4mv7QFM3p8q0JELENEoKUdhTTxMcI8+CUx5OgJ3miwBz6v KoQY//FZ49JxalP50xcUqW6COmujyz/hD62peqoDVt8vbEKcgafOAso2bA/VYwehXKWz 8yIdvlM//LY6j/T95rr+cZwB5KU0t2+rk84cEpEOCc2I5PXX5J6ZnCeM6LQZcNihZC7b qGgrvIp7FxwnacsCAfmjYqrgoPyeLi+JXbRFPw8UjFoIzvAvN5ipucG+XpRxYZbKmazT yTTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=/AALPOTg/zv4DddfH4+mNzel4BAeVyRKSnyodYnHBks=; b=mvAlyGMYhk6GHPFRApU02NQiaPX8kcacDrkIXsOpgy4E71VyKVPieDdHK05kAVsbjA /BIPLqdHCECTkaoge/MwnOUDr/4n/Y4yVpsUjSKYaIr7tCPFkC6Xi9xYse42nz8iCRBs oMH5MAe/prx7WLK0T8CurllRGAv1WHJvlk3HKr3Dqf2B8j7N2Og70LO1BDY1gJpv++eG D7ylXIOL1NTtalKG5C0Xwtjkgbmv1Ct7Q6xAiEK/9rjpo6Fk6ad58usEX3PZfcGUAoT+ +/9PoqktsDxzdKF1512tf7XEAQ1st8QZ60IA3fggUywFdJl1RX+2ms44G+yBKaHWrjmZ uV4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e9si464483edq.472.2020.05.13.14.36.00; Wed, 13 May 2020 14:36:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729327AbgEMVeS (ORCPT + 99 others); Wed, 13 May 2020 17:34:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728711AbgEMVeR (ORCPT ); Wed, 13 May 2020 17:34:17 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B3D3C061A0C for ; Wed, 13 May 2020 14:34:17 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jYz12-0004hG-39; Wed, 13 May 2020 23:34:12 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 2837B100605; Wed, 13 May 2020 23:34:11 +0200 (CEST) From: Thomas Gleixner To: psodagud@codeaurora.org Cc: john.stultz@linaro.org, sboyd@kernel.org, tj@kernel.org, linux-kernel@vger.kernel.org, saravanak@google.com, pkondeti@codeaurora.org, Joonwoo Park Subject: Re: [PATCH v3 1/2] timer: make deferrable cpu unbound timers really not bound to a cpu In-Reply-To: References: <1588444137-18651-1-git-send-email-psodagud@codeaurora.org> <1588444137-18651-2-git-send-email-psodagud@codeaurora.org> <87a72lkx9t.fsf@nanos.tec.linutronix.de> <87d0771swr.fsf@nanos.tec.linutronix.de> Date: Wed, 13 May 2020 23:34:11 +0200 Message-ID: <8736831pv0.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Prasad, psodagud@codeaurora.org writes: > On 2020-05-13 13:28, Thomas Gleixner wrote: >> psodagud@codeaurora.org writes: >>> It is not clear to me how to avoid #ifdef's in this case. Could you >>> please share an example here? >> >> The answer is further down already: > > I think, you are referring stub functions. Yes. I can reduce some of the > #ifdefs with stub functions as you mentioned and not all the cases > right? > I have introduced two variables timer_base_deferrable and > deferrable_pending and I can put stub function where ever is possible. > But it may not be appropriate to have stub function for all the > references of these variables right? Correct me if my understanding is > wrong. Is this a quiz or are you expecting me to make your homework? Thanks, Thomas