From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753411AbdAZTzp (ORCPT ); Thu, 26 Jan 2017 14:55:45 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:23915 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753060AbdAZTzn (ORCPT ); Thu, 26 Jan 2017 14:55:43 -0500 Subject: Re: [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va To: Andy Lutomirski References: <1485365586-21653-1-git-send-email-joao.m.martins@oracle.com> <1485365586-21653-2-git-send-email-joao.m.martins@oracle.com> Cc: "linux-kernel@vger.kernel.org" , kvm list , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Paolo Bonzini , Radim Krcmar , xen-devel From: Joao Martins Message-ID: <588A54D1.2000606@oracle.com> Date: Thu, 26 Jan 2017 19:58:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2017 05:25 PM, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins wrote: >> Right now there is only a pvclock_pvti_cpu0_va() which is defined >> on kvmclock since: >> >> commit dac16fba6fc5 >> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") >> >> The only user of this interface was kvm. This commit moves >> pvclock_pvti_cpu0_va to pvclock which is a more generic place to have it >> and adds the correspondent setter routine for it. This allows other >> pvclock-based clocksources to use it, such as Xen. > > With a minor nit: > > Acked-by: Andy Lutomirski > >> +#else >> +static inline void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti) >> +{ >> +} > > How about just not providing pvclock_set_pvti_cpu0_va() in this case? > It'll save three lines of code, and, more importantly, it will force > us to notice if we screw up the Kconfig stuff. Sounds good, will remove this then. Thanks! Joao