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 753F5A0544; Fri, 23 Sep 2022 10:49:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 17C2D400D7; Fri, 23 Sep 2022 10:49:51 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 90D354003C for ; Fri, 23 Sep 2022 10:49:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663922989; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=e2T1zrB5xjjWgUkirDOfPrXYcJIGSgJE0uoeBrWIWZ4=; b=KoQS8kBeMipkk/wx5no8DT1/u017P8tZ02dpH9fhflLGOS6JNk8RlNtfsbA3kePguUTwhD MQiefDGBBtm1A+lxoac28a8CH+alOkdSnk3IfQr+iz/ud2N9vFKQbyC1h8koHS0GAVLhNJ EmaGcUYcYfjshGnspluEhcwSXcjsSmY= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-599-q6lU50fJNCSyeKhj3EUptA-1; Fri, 23 Sep 2022 04:49:47 -0400 X-MC-Unique: q6lU50fJNCSyeKhj3EUptA-1 Received: by mail-lf1-f72.google.com with SMTP id q26-20020ac2529a000000b0049f564887d2so3967261lfm.17 for ; Fri, 23 Sep 2022 01:49:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=e2T1zrB5xjjWgUkirDOfPrXYcJIGSgJE0uoeBrWIWZ4=; b=vozymAPSG6rpNPxi/thCPFEzeT5edf/+dzNn1xnHi+KFXn9pmdptboTbaW7aFvpZv9 pAqDsret9hv2s6CGRcJr33PiiZpwYMkVm2Klph0VKRtGP10gU7WZqo9Og2oKwKdJgVtL vDoAjTT4HWXUJ9Jhb8Wjb8ULGnv+Gvpb1hkaVZP0Ln0SdhP6DyZU1bslsUzvyCy1qB4d ZcmciZaUk8DuqRR7Zb+GgbrM4TEFW3uCj6qGovj71l7aL/NR3Q/0TNRK/gBJMxOxP/gh xLGEmFvm5kKMSYIxa0gD4AX3M5hcOkIMZ4pZy97ol1Q79kb8ps49V8oQCqspAm/kqcKx R4GQ== X-Gm-Message-State: ACrzQf12/h3EMZ6kRnxDF5/bq7Ob4zdpNzgroPVSpUyI6YafGfwNZ4+e 7IqVVLAfnpuUcSOqBVh/g69qF2pquij8Cxyo6w/G7e8/sCEyejyPtrpl64+RzgoRr1C82rlpKyp 9ALs10aMizyxEl7d1KRs= X-Received: by 2002:a2e:8541:0:b0:261:b44b:1a8b with SMTP id u1-20020a2e8541000000b00261b44b1a8bmr2596936ljj.46.1663922986275; Fri, 23 Sep 2022 01:49:46 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6tAInPT1zj+Kg3MmsEyjPjd4x09sGSUyTNjoLB0qqi8YJ64A6LZ3UcG4mlxDm2ML5dIRD5qP8aCB5DE2BqGfc= X-Received: by 2002:a2e:8541:0:b0:261:b44b:1a8b with SMTP id u1-20020a2e8541000000b00261b44b1a8bmr2596914ljj.46.1663922986036; Fri, 23 Sep 2022 01:49:46 -0700 (PDT) MIME-Version: 1.0 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> <20220628103827.5060e318@hermes.local> <20220628182335.GD17875@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20220709092803.433e6644@hermes.local> In-Reply-To: <20220709092803.433e6644@hermes.local> From: David Marchand Date: Fri, 23 Sep 2022 10:49:34 +0200 Message-ID: Subject: Re: [RFC PATCH 11/11] bus: hide bus object To: Stephen Hemminger , Tyler Retzlaff , Thomas Monjalon Cc: dev , Bruce Richardson , Kevin Laatz , 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 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Sat, Jul 9, 2022 at 6:28 PM Stephen Hemminger 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. > > > > > > it's not i've sited at least one example of a mistake that becomes a > > > compile time failure where application code is incorrectly authored > > > where use of a pointer offers no such protection. > > > > > > > The Linux/Unix side prefers opaque structure pointers. > > > > Windows (and LLVM) uses numeric handles. > > > > > > > > At this point DPDK should follow the Linux bus. > > > > > > dpdk is multi-platform and unix does not necessarily standardize on > > > pointer to struct for opaque objects. freebsd has many apis notably > > > bus_space that does uses handles and as previously mentioned posix > > > threads uses handles. > > > > > > i understand that linux is an important platform but it isn't the only > > > platform dpdk targets and just because it is important doesn't mean it > > > should always enjoy being the defacto standard. > > > > > > anyway, i'll leave it for the patch author to decide. i still like the > > > patch series either way. i just think this would make applications more > > > robust. > > > > Thanks for this feedback Tyler. > > I would lean towards Stephen opinion atm, but I am not decided yet. > > > > For now, I'll post a v2, extending the series to other internal objects. > > We can conclude on this topic during 22.11. > > If you get chance to deconstruct API, switching to a numeric index > is safest similar to what Tyler suggested. Think of ethdev port number > and Posix file descriptor model. The advantage of an index is that > it can be validated more easily by the code that is called. This is still a heavy change in the APIs. The deprecation notice did not mention such change, and I don't think many people are aware of this suggestion. This would need more discussion but I don't want to block the series on concluding on this question. So I am for going ahead with the series in its current form. -- David Marchand