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 781ECA04B5; Fri, 18 Sep 2020 17:13:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 40C9C1DAE8; Fri, 18 Sep 2020 17:13:13 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 557AF1DAE7 for ; Fri, 18 Sep 2020 17:13:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600441990; 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=Uc6vZFC16h05ByoiqcJiEFv31pyZHFVB6RgFwYz+iNQ=; b=AB7rW9k2/nzrhkLpeh1sLWvbbo/ns3gJcPHap/MkYRospB4aOiGWItdmq54zqIIBzPNZGz yS6voiEdKzF79M4Gm60j+kfa2Nb/o+MMY6RSCLPYXvrk4rGJhXK9k+oIEhN5h6esSW/SZQ QueJhMMTRuRw4Y7lP5TWvGeBDq8LaZI= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-163-Cx55z6TgP6u33lXvVGwwxw-1; Fri, 18 Sep 2020 11:12:56 -0400 X-MC-Unique: Cx55z6TgP6u33lXvVGwwxw-1 Received: by mail-vk1-f198.google.com with SMTP id m129so1155224vkm.7 for ; Fri, 18 Sep 2020 08:12:56 -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=Uc6vZFC16h05ByoiqcJiEFv31pyZHFVB6RgFwYz+iNQ=; b=cMc9DrQYeEZaPbeq9tPKL92FTunhVhVPrLJx+ckBMPQzmDZBUnqeanVk7LB7LpzXmb ERBtpWp1oqM4zaJg4dcqPrF1Ik5a3xsT0EcKzzUcS3i8+fQrwWyLhva/vE8D3yEOsyQI ImERcIvXOsXuN/OBg6MQpUzmaxVBiSTNrZUNnFlJIkUa1K/IqWGdl5dniw80BDseBU56 wlFgVOsy68fr8uLDyUxslNy0+uNUhyi3c4y6RK/CHJqugECEaf5NNOksCoCO8uv4wRsy T48/3vB7Jev7bmwgzX5Z1V7xI9Q46vt8A+8SqometC1U44CnDMgpfVoFw++PQ35Osy8g IEZA== X-Gm-Message-State: AOAM5338rhZ9oBGG/h+78Hpz3adCYXULQZ8XM/liUjoz7rEpxDAJVrRL gZ0lf6XdeTMdacDuETzgT1ZoX9EjJZC7Dq4UQyLmESJjSwzuQxRTXBxTCPaB66jdBnRgV7fCruR n9Ke1By3rBP81ov3x1ko= X-Received: by 2002:a05:6102:20e:: with SMTP id z14mr20705045vsp.17.1600441975493; Fri, 18 Sep 2020 08:12:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyatceH7x5qGyM1Hr1anQ7m3slGRULrqr2YzF7S5GfpioCal28P9yZv6HLdSkwDMJGDXzrMbicuaCETX4UlXqg= X-Received: by 2002:a05:6102:20e:: with SMTP id z14mr20704996vsp.17.1600441975125; Fri, 18 Sep 2020 08:12:55 -0700 (PDT) MIME-Version: 1.0 References: <20200916164429.244847-1-bruce.richardson@intel.com> In-Reply-To: <20200916164429.244847-1-bruce.richardson@intel.com> From: David Marchand Date: Fri, 18 Sep 2020 17:12:44 +0200 Message-ID: To: Bruce Richardson Cc: dev , Andrew Rybchenko , "Yigit, Ferruh" , Thomas Monjalon , Ray Kinsella Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility 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, Sep 16, 2020 at 6:44 PM Bruce Richardson wrote: > > As flagged previously on-list, there are a number of macros used to specify > what libs and drivers are enabled in the build which differ from the > equivalents used with make. This patchset is one possible approach to > fixing these, but as part of the investigation some issues were hit where > I'd like additional input to ensure we are ok with the approach taken in > this set. > > First, a problem statement: > > * While the make build defines generally followed a pattern, there were > many instances where the defines were unique. These can be seen in the > values defined in patch 4. > > * The NIC PMDs had two separate standards for the defines - some (the > physical device drivers) tended to have the _PMD at the end of the > macros, while the virtual drivers had it in the middle. Since the > majority seemed to go with it at the end, meson chose this option. > However, as can be seen from patch 4, a number now need special handling > for compatibility > > * This "_PMD" at the end made its way into other device classes, such as > crypto and event, but it appears that the standard for these classes from > make is in fact the opposite. Therefore we have had for the last 2+ years > conflicting macros for crypto, compression and event classes. > > * There is also the question of how important compatibility for these > macros is, especially since we have had numerous incompatibilities > without it being reported before. There is also the issue of the > deprecation process for macros, since these are not part of any ABI. The main use I can think of for an application is controlling calls to specific drivers API. This is how we caught this issue, with testpmd silently dropping code/feature. My impression is that people are only starting building with meson now they are forced to: even DTS only recently started building with it. This is why I don't think the absence of complaints is a good indicator. > > What's done in this set: > > * Firstly, and missing dependencies on apps or examples had to be fixed, > where a dependency was missed because it was never needed due to the code > being stripped out because of a missing macro. > > * Secondly, since it is likely that use of the defines from make is more > widespread than those from meson, the defines for the crypto, compression > and event classes are changed to align with the make values. Just in case > though, temporary code is added to drivers/meson.build to redefine the > old meson values too, and a deprecation notice is added for these. The > hope is that we can then remove this temporary code in the next release, > leaving us with just one macro style for each driver class. > > * Thirdly, we add an additional set of backward compatibility macros for > the ~30 special-cases, where the meson macro template does not match that > defined for make. Again, this is intended to be temporary and a > deprecation notice is given for the macros in that file. > > * Finally, we replace all instances of the old macros in the codebase with > the newer versions. While the work done in the first four patches (steps > 1-3 above) should be ok to backport, this final patch is not suitable for > backporting. However, it is relatively simple to produce a new patch for > backporting which allow either old or new values to be used in macros. The series looks good to me. Thanks for coming with this quickly. > Open issues/considerations after this patch: > > * We still have inconsistencies in our driver macro and naming templates. > This is just a nice-to-have, but if people are ok with generally having a > breakage in our macro defines, we could clean this up a lot further. > Notice how 'net', 'regex' and 'vdpa' have '_PMD' at the end, while most > others have it before the name. Notice also that many device classes have > the class at the end of the template, while bbdev has it in the middle. > $ git grep config_flag_fmt -- drivers/*/meson.build > drivers/baseband/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_BBDEV_@0@' > drivers/bus/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_BUS' > drivers/common/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_COMMON' > drivers/compress/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@' > drivers/crypto/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@' > drivers/event/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_EVENTDEV' > drivers/mempool/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_MEMPOOL' > drivers/net/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD' > drivers/raw/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV' > drivers/regex/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD' > drivers/vdpa/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD' I can see the meson implementation kept a part of the chaotic aspect of the make implementation ;-). I like Andrew proposal. +1 even if this is "nice to have". Cleaning the .so names is nice too, and I don't see an impact for applications now that we provide a pkgconfig file. > > * Are we ok to remove the older macros after one release of deprecation, or > do we need to wait to next API window. Waiting for one release or more won't make a difference for people who only upgrade with LTS. If we go with the change, I'd rather drop the API compatibility in the next release 21.02, as this is an "easy" thing to fix for applications that recompile with intermediate releases. -- David Marchand