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 12EC242B1A for ; Tue, 16 May 2023 01:20:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 108B142BDA; Tue, 16 May 2023 01:20:37 +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 F2E5940A7A for ; Tue, 16 May 2023 01:20:34 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-643465067d1so9864852b3a.0 for ; Mon, 15 May 2023 16:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1684192834; x=1686784834; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=VmLSbaJ1CmlLefQp/QGSiF67hYIEY8Lxvs8RilveGzU=; b=0SJ93oj7IjaKYFGQkEvhhJu3lAqW58MXGOyuoFj9Geod/dxTTa7RlrT5HtWKKYqttz Kdd/UXQfMqcr2ypTmeOwfPlugzgioTsPVWIeSFNZaqnzZI73eiQM5P0KpGsCO55bQ998 TAuhNBiqPyF4DTNilTKZtM1Lh+0Rlaxh+1UMeV7FZpZc5X/v/8m7LlreubVbKRlSsvyT yc/htoj3IsjPZ4ITGwtPUQjuv4PFOWGb7VMjLnfOdWa0Xop7hrB5lIkqAuwdRocSPisu iG0jAEoZYMwtvDB/LETaei7F1qS39UtzKmOU/Sx9FIfs4oPD2/kl9Miypz5kScI+8BE6 xlPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684192834; x=1686784834; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VmLSbaJ1CmlLefQp/QGSiF67hYIEY8Lxvs8RilveGzU=; b=VNOYrvgx+hydA8xPRQf7+a/G4YwhyEXdYZHFPw/bG53oNJ5nrexCzMdw65F1RzBfzQ kSLIFxtI8CJEuixfdpm3kM/w+AxCfknqEZy+KSoFTktzoAW7Lb3HgnHY7AWKhfzOfMK9 GjUiwhqd3I76VRBBTPDaG4iaAEppOAxTykxARb3tIwZtU3S2OBFmZ6osrtf7m2YhduG+ EB4jRc9xwQ8vKjmZSC8hmIdfSpOp70XP9TDnY9pPKRujpoFLid4jKKdG+/q1vtE8YmBD ojtP6pY7NKHtk0+TWkB6g5LfV9bBafC0/gZWoA7mOtnJZ3HRUJwR5dFU7A2Z53pmySle dB5Q== X-Gm-Message-State: AC+VfDxwCF6glVp4NbHZTxoePMojSrch5zX18ygR8o1+4k0c/C4x+g5M /KD941xolZ7bPwOp5Xt/OBExNg== X-Google-Smtp-Source: ACHHUZ5iv2EuLRAFwsQmp5XMihoVGBNLk1bXj8f9nst7sduW6JNJXXYGJQAn+XX8rdo9VWXbjPMwDg== X-Received: by 2002:aa7:888c:0:b0:63b:859f:f094 with SMTP id z12-20020aa7888c000000b0063b859ff094mr47792721pfe.20.1684192834023; Mon, 15 May 2023 16:20:34 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id f8-20020a631008000000b004fab4455748sm12171161pgl.75.2023.05.15.16.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 May 2023 16:20:33 -0700 (PDT) Date: Mon, 15 May 2023 16:20:32 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: David Christensen , dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH v2] net/tap: resolve stringop-overflow with gcc 12 on ppc64le Message-ID: <20230515162032.36a4f3ec@hermes.local> In-Reply-To: <165a233b-b41b-3a65-1866-5b7c94993b40@amd.com> References: <20230322212439.524725-1-drc@linux.vnet.ibm.com> <20230323170145.129901-1-drc@linux.vnet.ibm.com> <165a233b-b41b-3a65-1866-5b7c94993b40@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Tue, 16 May 2023 00:14:52 +0100 Ferruh Yigit wrote: > Hi David, > > I confirm the build error, btw it helps to future references to put > build failure to the commit log, > > and change is reasonable to convert PMD local parse function to an API, > BUT my concern is they don't behave exactly same, which changes user > interface of the driver. > > The 'rte_ether_unformat_addr()' API expects exact "XX:XX:XX:XX:XX:XX or > XXXX:XXXX:XXXX" format. > Like 'parse_user_mac()' accepts 'a:a:a:a:a:a' as input, but API requires > '0A:0A:0A:0A:0A:0A'. > > This is a small change but still may create a bad experience if an > existing user/script hit by this, and I believe we don't have a strong > reason to change the interface. > > > To keep behavior same, we can either update 'rte_ether_unformat_addr()' > to accept singe chars between ':', > or fix the existing 'parse_user_mac()' for compiler warning, what do you > think? This is the kind of change where a simple release note will suffice. Not sure if anyone beyond some test script would ever use this anyway.