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 13EA4A0544; Tue, 28 Jun 2022 19:38:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A571F400D7; Tue, 28 Jun 2022 19:38:33 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id 3F41D40042 for ; Tue, 28 Jun 2022 19:38:32 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d17so12621907pfq.9 for ; Tue, 28 Jun 2022 10:38:32 -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=4HsF2Evyeh0ovAf2LDECVpveXF/0dvb4+tvVMrYm4lw=; b=Vgn5k0yr7j3TU0uliid8uQuIDFU9/5ip2NaLxzqFn9x4IdgSoSs/ozdeFUGsM8gr9T ij9tbMT+pnQDiJYG3twEKBQI9ZfAxKaV54lZicRdvw7+dFxNCNbuYMTMdoSoARqcnY40 QT0ML3G1uVd0Qh71t/1B3FNYzWL0Kbx9cIKkGfUeY8d76ZEIvbOfWpc2kCfG0U3ILx1L R1N3xsSdz4ny8+JQfW3L0m7zt51awNugpRczkfB0O943XVojv6m7FeiRBoeJPjJN1PWc Ue5lpE7HWBjESDi7pIhSGFXiJqYkmGTOsycnkh4Dr2vU3to0KPak3xVz277kyEbFdUgb COig== 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=4HsF2Evyeh0ovAf2LDECVpveXF/0dvb4+tvVMrYm4lw=; b=XNy0ix4ZS/YbwgperS2YUIGlKiKerOGphmWg2nuiwkgqGi4eA/SQuNrq/JwTMAi0HD DQgUrGz8EuZglwvXVpVo5qVfBL2UeCRBnSE6VjRQX+DTlzBfaBl8FdGhRmXiH9GA/SAs qQnsKMx0yvtqR+0LbID5Ktz8lEFkFg3fO1OOLQ+Q9+yLSIVpvspY6eNuuwnStiAGDJHz BIBNRHHZAZivtt4MFBT3EI/nk36314rzNWZk8mghPzWBMHxFyKZKNh1ZhLS0s/Up4KZz uotNPBCF2ppDrpleKvHalriV8OvGM5YjpeAGrS2bVzD1HHnKNxQl1fB0cTX8LXsgc9no IiGw== X-Gm-Message-State: AJIora/aemcMycx9En4F59Mg2gvAFobinLdntU25soc95IWloukoOxui qH3rLWsVAOkUpE9CQfSOrYBLng== X-Google-Smtp-Source: AGRyM1vrsaiR65lu9asgSOQXNROQZvRk/RQveDXTBKVx0UZI/J2jXDXTMDTENEyMR6IE0Mb0ikXwHA== X-Received: by 2002:a65:6cc9:0:b0:399:26da:29af with SMTP id g9-20020a656cc9000000b0039926da29afmr17960759pgw.489.1656437911274; Tue, 28 Jun 2022 10:38:31 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id x124-20020a626382000000b00525231e15ccsm9756217pfb.113.2022.06.28.10.38.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 10:38:30 -0700 (PDT) Date: Tue, 28 Jun 2022 10:38:27 -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: <20220628103827.5060e318@hermes.local> In-Reply-To: <20220628170712.GC17875@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> <20220628092905.2da82a8c@hermes.local> <20220628170712.GC17875@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 10:07:12 -0700 Tyler Retzlaff wrote: > > > 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. > > as i mentioned you can use an inline/internal function or even a macro > to hide the cast, you could provide some additional integrity checks > here if desired as a value add. > > the fact that you expose that it is a struct is an internal > implementation detail, if truly opaque tomorrow you could convert it > to a simple integer that indexes or enumerates something and prevents > any meaningful interpretation in the application. > > when you say it is safer to debug i think you mean for dpdk devs not the > application developer because unless the app developer does something > really gross/dangerous casting they really can't "mishandle" the opaque > object except to use one that isn't initialized at all which we > can detect and handle internally in a general way. > > i will however concede there would be slightly more finger work when > debugging dpdk itself since gdb / debugger doesn't automatically infer > type so you end up having to tell gdb what is in the uintptr_t. > > anyway just drawing from experience in the driver frameworks we maintain > in windows, i think one of our regrets is that we didn't do this from > day 1 and subsequentl that we initially only used one opaque type > instead of defining separate (not implicitly convertable) types to each > opaque type. It seems to be a difference in style/taste. The Linux/Unix side prefers opaque structure pointers. Windows (and LLVM) uses numeric handles. At this point DPDK should follow the Linux bus.