From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 86895A0487 for ; Wed, 3 Jul 2019 11:10:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 204F51BE0E; Wed, 3 Jul 2019 11:10:34 +0200 (CEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id 7DE431BE0D for ; Wed, 3 Jul 2019 11:10:32 +0200 (CEST) Received: by mail-io1-f68.google.com with SMTP id s7so2982458iob.11 for ; Wed, 03 Jul 2019 02:10:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hg9DTaFpXNk+dgGmKMUiT4bTPMGoq17AAxKA5K00W60=; b=lQuRbfK0t9z4rZnZx18Aq9PyPXvrhEdZrMd/pr+OygBULYuWk/+CGcj74Y4M6mQ5dZ /hxXGlYUOYr+wOFfisc7is9GT+kizXpwZhlWSl044DCI6DQ4a0jMZZS/iCuY0OyRS5g4 Im0K07fODV1rY6g9zmkLd/G4xODnir8Heydqd2wPCcWz78gKJCRCJf+IUDQ0Yye0BHFZ VshEZ0NrpZwG5ufFM54hpvkFB3c5ZB5HE55wFmprlpVaJN9JfKmZhuHDghTJy9G1ZQas RWDyfci2IdiScqAdayqJXeipdGNMhef0LXK2x1l8LxKBuYOgH6XUSG1cwLy1/OiR8pAE w7yw== X-Gm-Message-State: APjAAAWpNl5nA7tVSlRVP+YXs4LTLsLoEHH3V/xtvLcw16W3kv/dyNkH KpaUwG/9BhjFB/02nEvGFcg8xFj/W4KmxTNaeZ8Wfg== X-Google-Smtp-Source: APXvYqzLYhenb6HzJoU7dMlS6Epm8hG7643HwN7KuPc0/ZcUQ1oYQiwjnyfZ0YmDdE6jlL+wt6QaBGx7e29vg1hQUdM= X-Received: by 2002:a6b:2b08:: with SMTP id r8mr21642ior.34.1562145031893; Wed, 03 Jul 2019 02:10:31 -0700 (PDT) MIME-Version: 1.0 References: <20190703054508.22824-1-tiwei.bie@intel.com> <20190703073314.GA18868@___> <20190703075657.GA20458@___> <20190703081550.GA25721@___> <20190703085929.GA30592@___> In-Reply-To: <20190703085929.GA30592@___> From: David Marchand Date: Wed, 3 Jul 2019 11:10:21 +0200 Message-ID: To: Tiwei Bie Cc: dev , "Burakov, Anatoly" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jul 3, 2019 at 11:01 AM Tiwei Bie wrote: > On Wed, Jul 03, 2019 at 10:26:39AM +0200, David Marchand wrote: > > This patch breaks the ABI by extending rte_pci_device. > > You must rework it to avoid this break. > > I didn't expect it to be merged in this release. I just want > to draw other's attention on this and kick off the discussion > (it would be great if you would like to share your thoughts > on this). If there is a way to avoid extending rte_pci_device, > it would be definitely great. But if we have to break it, then > we would want to send out the announce as early as possible. > What we have here is a vfio private thing, we don't need it to be exposed. Did not think it through yet. How about having an internal (as in, in the pci driver code) representation of the pci devices? This internal structure would embed the rte_pci_device exposed to the others subsystems and the applications and the vfio code would just get what it wants by using offsetof? -- David Marchand