From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D340FA057F; Tue, 28 Jun 2022 18:29:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7CA184069F; Tue, 28 Jun 2022 18:29:15 +0200 (CEST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mails.dpdk.org (Postfix) with ESMTP id 01295400D7 for ; Tue, 28 Jun 2022 18:29:14 +0200 (CEST) Received: by mail-pj1-f54.google.com with SMTP id g20-20020a17090a579400b001ed52939d72so7776038pji.4 for ; Tue, 28 Jun 2022 09:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=6UAx4f17sgNnnomSvO8Y7kx52sgkENd5Obyhq/KZ2C0=; b=g08zASs69VdS2gcoaOkQJar3GPo/4jgOhG/I0zZVHO//IUzlliNDMGf2mMxiOGwpLe KfzQd7l1/U9nMAlqAp+39CARqIDyXVPF5czRjxk8QPPN+jQCXSigwY4Fg19xculy+1aP dH2n4hGYXhYRkFKHX7pKP+OxL9jLG/2X5RdcHMKs7TMgKkT6vyM59iXvHlFOHzYBI7yZ sRonngUYhTGZhci+YnlYrJOLM8dOdJel1K0lEUHZ0Ss1uHVjDhlb58dg0e996k+aWvus efIg/pMA+tHuKAkNKWeyDCd5Hd+Qq1r1NjiRxJEKmJMdwdOQTuv9l99vv/eirREHxjNs RcaA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=6UAx4f17sgNnnomSvO8Y7kx52sgkENd5Obyhq/KZ2C0=; b=EhKU89arE9xIbv29imSnUTqh942iiFZIPkzgBb9XeE8Mc4TUO3nG7ZPl1HMlaz+ZEf PN2T1Dt4PsdTFXxKqMmGw0FL+SuqdVCeBSWeeaQnstp22U4EGD/Ga8pk55GDetvPBhAK aUbR+/h4l3shs768L/8ZTAIlzMJbsTnC36jRvK70f0oPUnuuflB1fqCv2AKGNk9E1JBR Zdo5qoYiE74+j3qbo8yGF5wsqVqBXO+w6Cwk15sHbnFNCxvOoYaRCY508OD47QAFskKE E7lM1tXLis7FHVQcTdjs8XCuA7vzc/NWoncENzsjA17h7Q2esqydxsd1l9ZgfOiObERG bz3g== X-Gm-Message-State: AJIora8EKriqxPhpLWZFdSAEh72TjsDfUrIhjTnHLjYHP9AvO6rXGiJZ L1pTA4YXbHmb915ZvlAgtSbRkA== X-Google-Smtp-Source: AGRyM1sy73w/ny30I7d3C8RXvjn/GS2CXk43ZlQF4sW3fk7OOi9dWtZMQrV/zqietyD+jicqYpl1hw== X-Received: by 2002:a17:90b:3b82:b0:1ec:ac0d:5d3b with SMTP id pc2-20020a17090b3b8200b001ecac0d5d3bmr494289pjb.158.1656433754131; Tue, 28 Jun 2022 09:29:14 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id n19-20020a635913000000b0040df0c9a1aasm4621978pgb.14.2022.06.28.09.29.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 09:29:13 -0700 (PDT) Date: Tue, 28 Jun 2022 09:29:05 -0700 From: Stephen Hemminger To: Tyler Retzlaff Cc: David Marchand , dev@dpdk.org, thomas@monjalon.net, bruce.richardson@intel.com, kevin.laatz@intel.com, Parav Pandit , Xueming Li , Hemant Agrawal , Sachin Saxena , Rosen Xu , Stephen Hemminger , Long Li , Chas Williams , "Min Hu (Connor)" , Matan Azrad , Ray Kinsella , Ferruh Yigit , Andrew Rybchenko Subject: Re: [RFC PATCH 11/11] bus: hide bus object Message-ID: <20220628092905.2da82a8c@hermes.local> In-Reply-To: <20220628162213.GA17875@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20220628144643.1213026-1-david.marchand@redhat.com> <20220628144643.1213026-12-david.marchand@redhat.com> <20220628162213.GA17875@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 28 Jun 2022 09:22:13 -0700 Tyler Retzlaff wrote: > On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote: > > Make rte_bus opaque for non internal users. > > This will make extending this object possible without breaking the ABI. > > > > Introduce a new driver header and move rte_bus definition and helpers. > > > > Signed-off-by: David Marchand > > --- > > ... snip ... > > > -struct rte_bus { > > - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */ > > - const char *name; /**< Name of the bus */ > > - rte_bus_scan_t scan; /**< Scan for devices attached to bus */ > > - rte_bus_probe_t probe; /**< Probe devices on bus */ > > - rte_bus_find_device_t find_device; /**< Find a device on the bus */ > > - rte_bus_plug_t plug; /**< Probe single device for drivers */ > > - rte_bus_unplug_t unplug; /**< Remove single device from driver */ > > - rte_bus_parse_t parse; /**< Parse a device name */ > > - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */ > > - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */ > > - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */ > > - struct rte_bus_conf conf; /**< Bus configuration */ > > - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */ > > - rte_dev_iterate_t dev_iterate; /**< Device iterator. */ > > - rte_bus_hot_unplug_handler_t hot_unplug_handler; > > - /**< handle hot-unplug failure on the bus */ > > - rte_bus_sigbus_handler_t sigbus_handler; > > - /**< handle sigbus error on the bus */ > > - > > -}; > > since we're overhauling anyway we could follow suit with a number of the > lessons from posix apis e.g. pthread and eliminate typed pointers for a > little extra value. > > > +struct rte_bus; > > +struct rte_device; > > to avoid people tripping over mishandling pointers in/out of the api > surface taking the opaque object you could declare opaque handle for the > api to operate on instead. it would force the use of a cast in the > implementation but would avoid accidental void * of the wrong thing that > got cached being passed in. if the cast was really undesirable just > whack it under an inline / internal function. I don't like that because it least to dangerous casts in the internal code. Better to keep the the type of the object. As long as the API only passes around an pointer to a struct, without exposing the contents of the struct; it is safer and easier to debug.