Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp145873pxk; Thu, 24 Sep 2020 01:44:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwIIYXi9l7F6yeo02uy6C/eZtIXqYCq6JKAXHVkq2UInPvFbr49HYU7u9fdHBkjWcRKbdd X-Received: by 2002:a17:906:8687:: with SMTP id g7mr3580874ejx.129.1600937048352; Thu, 24 Sep 2020 01:44:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600937048; cv=none; d=google.com; s=arc-20160816; b=LcEnnHg6hMe1vgvF9HOdjTfVL8lkwuK4L5hyUG2ppRZd0D/cIxfUiQtx4SIu3pcitg 3S8Mulx2SpDzLBnIYSXxrwlU2gOXQ31hT2gVh1YCVM/0xUhj4ZW+xZhXqteRY0rh5Kdq qFN431IT9ajNBwrpp1lq0qZiQcCNWwx/sm82JIVULkDMHPakvog5c7t/EIgX3bskf+8U QORKSsZdLNhE0bgFBRH+kt1EVAwbWBUcg3gjeyM/X1IuFdVcUKT1shsWNObxJIRfseY5 F3/DkZf8jpyNn6uFfF28Wr6nJmErFKdh8GQ0y+gTOaKyjdx+TrJ5dMsSSTAODmXWSAAM +3jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=KaTfIjt8i0s8A3kHJdHaqaQDnlUSfFP9askg/3MoiNA=; b=a5WYWxFePjfXN8OAJZLX32a8PMDD1gCn0WQuV9WE6L7yi07ynV0aH7eO3yvCp9VJO3 2XE7lnfLhaC6EbDxALBimdiAjE2dZtmboxkxkRpoFslT7rfzPvfHm83q7I4zsLGS0WNE 8ydZ3XUwXpqodhm6aOZT4+t0EDAjGh8cxK42FE24I2XUtr3DzDhadilNqow1Uu7ez08m PDJ39TquXh4c4wi7pv+fcqe8WhwWqcrL0H4CuWvwgipRrwGN+0JnOrNTP4aJGuPX+Vsp RRTwBXD7zbZ0hUJpb40btHxC8gKGuLpwbJVk7tYclJ4woxFKEalUpD5J/Yvqg00O9wu+ H2Qg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay19si1661798ejb.626.2020.09.24.01.43.43; Thu, 24 Sep 2020 01:44:08 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727256AbgIXIkV (ORCPT + 99 others); Thu, 24 Sep 2020 04:40:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726837AbgIXIkU (ORCPT ); Thu, 24 Sep 2020 04:40:20 -0400 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ECB3C0613CE for ; Thu, 24 Sep 2020 01:40:20 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id D53C3295; Thu, 24 Sep 2020 10:40:17 +0200 (CEST) Date: Thu, 24 Sep 2020 10:40:16 +0200 From: Joerg Roedel To: Jacob Pan Cc: Jacob Pan , iommu@lists.linux-foundation.org, LKML , Alex Williamson , Lu Baolu , David Woodhouse , Jonathan Corbet , Jean-Philippe Brucker , Eric Auger , Yi Liu , "Tian, Kevin" , Raj Ashok , Wu Hao , Yi Sun Subject: Re: [PATCH v9 3/7] iommu/uapi: Introduce enum type for PASID data format Message-ID: <20200924084015.GC27174@8bytes.org> References: <1599861476-53416-1-git-send-email-jacob.jun.pan@linux.intel.com> <1599861476-53416-4-git-send-email-jacob.jun.pan@linux.intel.com> <20200918094450.GP31590@8bytes.org> <20200918101108.672c2f5a@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200918101108.672c2f5a@jacob-builder> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jacob, On Fri, Sep 18, 2020 at 10:11:08AM -0700, Jacob Pan wrote: > On Fri, 18 Sep 2020 11:44:50 +0200, Joerg Roedel wrote: > > > On Fri, Sep 11, 2020 at 02:57:52PM -0700, Jacob Pan wrote: > > > There can be multiple vendor-specific PASID data formats used in UAPI > > > structures. This patch adds enum type with a last entry which makes > > > range checking much easier. > > > > But it also makes it much easier to screw up the numbers (which are ABI) > > by inserting a new value into the middle. I prefer defines here, or > > alternativly BUILD_BUG_ON() checks for the numbers. > > > I am not following, the purpose of IOMMU_PASID_FORMAT_LAST *is* for > preparing the future insertion of new value into the middle. > The checking against IOMMU_PASID_FORMAT_LAST is to protect ABI > compatibility by making sure that out of range format are rejected in all > versions of the ABI. But with the enum you could have: enum { VTD_FOO, SMMU_FOO, LAST, }; which makes VTD_FOO==0 and SMMU_FOO==1, and when in the next version someone adds: enum { VTD_FOO, VTD_BAR, SMMU_FOO, LAST, }; then SMMU_FOO will become 2 and break ABI. So I'd like to have this checked somewhere. Regards, Joerg