From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B5D9C433EF for ; Wed, 8 Jun 2022 16:01:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244676AbiFHQBw (ORCPT ); Wed, 8 Jun 2022 12:01:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244646AbiFHQBu (ORCPT ); Wed, 8 Jun 2022 12:01:50 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCB94115CB4 for ; Wed, 8 Jun 2022 09:01:43 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id 15so18724931pfy.3 for ; Wed, 08 Jun 2022 09:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LeJNBwVypsDaHqUgIqimlROAW7mu+bPC1d5HEcwRpvQ=; b=Teu5cyfnYPbr7uT/ShpogpHQXBLyCTusIjkw9kGxDV8yxdr/79ADs7o5HOnxe9rwEC ARdBMF5Q8tbWStHl3XY6se1Lf9k/R91efCPmXufsfpMedPpJLIn53yJiO4pq6zySsbLq vgISwYeXXgcSYh3DpN8t6tSiHGl62SlUr3RgM8PH8jPEfSv+hsqAjgZCmabB3eC8v9z+ u+Ic1itts2HcU0halHybHiiVckFZyaMVt6uivmkzo2tkP2daB8eUY/GaW4EJs0slYhxl Wo+RbiJKXE7ZSPK8s6VyXFRVgBMj41Hi7glisJXN+GGEA+mbHbbyV4/QN1ISC+V2otS1 9oKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LeJNBwVypsDaHqUgIqimlROAW7mu+bPC1d5HEcwRpvQ=; b=IKon26Mh6JDYpvoaSx46R+JnvoG5Pu4ODQREN4qbL9oWtyEepAA2DE2ncy+tUzb1pH RJB5fxnDfjL2tylqdmga9l+bclIZhb+vGmFw9ehBpf2pPxpePrjp4tXacpHnBDi/Hub3 HLdVdzSGW2kVUexlZivpisoZUtt0g+2vljOkmUwq7Rb/VdaquNtcb4vJ8lXrFQcfbo3w E/fFOBWFt3a2rFRKojLU8mRltviczSRifFAyifPKjfERG9jiRApJGJVrPoBGLY29P326 UKOIFUO2K5jOHEX5L8Cycf9Qtwb77INZgi7Q+vUBEDiaKfcUjIO2NuY/f+mzbbQvbAHu K50Q== X-Gm-Message-State: AOAM531b1lKpzN7o3vYbCha/cmB02tG5moYvSYwivzXs5V5aAuy1wy8j +bbuEXvid4BnCUIRTU1IuEtpAw== X-Google-Smtp-Source: ABdhPJxr4aFzDSm2gR3L5oc1+Z0R77JVGx1LTOJD+08ZU36kuuWiZ6CxKRr3EAWOadaRHx0+LfJrpg== X-Received: by 2002:a63:305:0:b0:3fc:7f18:8d7 with SMTP id 5-20020a630305000000b003fc7f1808d7mr30349801pgd.186.1654704102947; Wed, 08 Jun 2022 09:01:42 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id je21-20020a170903265500b00163b02822bdsm14834409plb.160.2022.06.08.09.01.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 09:01:42 -0700 (PDT) Date: Wed, 8 Jun 2022 16:01:38 +0000 From: Sean Christopherson To: Andrew Jones Cc: Paolo Bonzini , kvm@vger.kernel.org, Vitaly Kuznetsov , David Matlack , Ben Gardon , Oliver Upton , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 048/144] KVM: selftests: Rename 'struct vcpu' to 'struct kvm_vcpu' Message-ID: References: <20220603004331.1523888-1-seanjc@google.com> <20220603004331.1523888-49-seanjc@google.com> <20220608151815.7mwlj3eppwmujaow@gator> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220608151815.7mwlj3eppwmujaow@gator> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 08, 2022, Andrew Jones wrote: > On Fri, Jun 03, 2022 at 12:41:55AM +0000, Sean Christopherson wrote: > > Rename 'struct vcpu' to 'struct kvm_vcpu' to align with 'struct kvm_vm' > > in the selftest, and to give readers a hint that the struct is specific > > to KVM. > > I'm not completely sold on this change. I don't mind that the selftest > vcpu struct isn't named the same as the KVM vcpu struct, since they're > different structs. I don't care about about matching KVM's internal naming exactly, but I do care about not having a bare "vcpu", it makes searching for usage a pain because it's impossible to differentiate between instances of the struct and variables of the same name without additional qualifiers. > I also don't mind avoiding 'kvm_' prefixes in "KVM selftests" (indeed I > wonder if we really need the kvm_ prefix for the vm struct). Same as above, "struct vm *vm" will drive me bonkers :-) > If we do need prefixes for the kvm selftest framework code to avoid > collisions with test code, then maybe we should invent something else, rather > than use the somewhat ambiguous 'kvm', which could also collide with stuff in > the kvm uapi. Potential collisions with the KVM uAPI is a feature of sorts, e.g. tests shouldn't be redefining kvm_* structures (I'd prefer _tests_ not use kvm_* at all, and only use kvm_* in the library), and I gotta imagine KVM would break at least one real world userspace if it defined "kvm_vcpu". That said, I don't have a super strong preference for kvm_ versus something else, though I think it will be difficult to come up with something that's unique, intuitive, and doesn't look like a typo.