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 B8FA9425DF; Mon, 18 Sep 2023 20:25:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A3D13402D9; Mon, 18 Sep 2023 20:25:26 +0200 (CEST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id B0D724025D for ; Mon, 18 Sep 2023 20:25:25 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1bd9b4f8e0eso35970335ad.1 for ; Mon, 18 Sep 2023 11:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1695061524; x=1695666324; darn=dpdk.org; h=content-transfer-encoding:mime-version:message-id:subject:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=xMmm6soIVqSyUYUp1LOooh/c7gCfK2vm5JcFpBzmd5c=; b=Ne6za8ks+QZF9pPq2y77SBUxHIdEU6jF55R9eORXk+wFrN46HVGEUHa/wFUZmq1J9n OhWrj70RHE1Dg8LB5Yd4MeoZFHW3dbH3hHcuLwLk/n74D+xe3dPoFAR/7I6Q8b5Ko2/4 0MsqfuqoxDJ+DzMl+3/DXgnCHoSNq7zb0argAL0hJ/v0AM7fxkCaS+eubDSWLgsHOD2c PKVzhL42CTafpP1BJHYp8/cCTpROL6c3Vp664NlTXVTUT7ahG85ivKADpbuU95iqsMQA HnLlbGyLqleKVfAxeyXthSnGiaTYcNmHT7wEMoz2P8s2MQhGyp4FCHTml/c//YkVE/0G TbEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695061524; x=1695666324; h=content-transfer-encoding:mime-version:message-id:subject:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xMmm6soIVqSyUYUp1LOooh/c7gCfK2vm5JcFpBzmd5c=; b=pfaERQc5GGxMgkiU+luFjk+bklKsdgpRsOnI2zyuMRpLSiSGut1jmB8C0Jx91+gbqO KIvxPaG1zWTJiERN8gWcLrgGNSdHRfKWFEefgOw6vIdWDQyD4DOod3YKeFxtLH9ikhuK aPpNaj+PKtS+6+qH5e8PzxwN7AGuhOiMPDx/LVGUfDrGJP/shJfMRDHNPsfryttgX4Ju X5CmeiCi0ZvwpETKWapufs9Thr2AZMSSv+hM5IqQflYrkygm7G6aM2xyG+0kcOHZ/xCo MLbRo+hIe7QSmlGispswqzvEVOoRewlPbo0ShOu9mNzmugqHbsV/6F9gFZFBuB2zBYBk NQPg== X-Gm-Message-State: AOJu0YwtFW6s1OG90ZTAvrEs7z/tgpCna5vxyclMCCK8QHLCTPdSGLMg 5jZQNXH9d4J3dnxrMj8H2U3qTzF7d5P1BIsgZ/045g== X-Google-Smtp-Source: AGHT+IEvjsOEgjpqnWbXsUxiRglaIIltBeyN9Vb84cUokE/VfKIkyUTsvLAy8xz1iCZON5RSsnFRig== X-Received: by 2002:a17:903:32cf:b0:1b8:8ff5:2cee with SMTP id i15-20020a17090332cf00b001b88ff52ceemr9550301plr.64.1695061524309; Mon, 18 Sep 2023 11:25:24 -0700 (PDT) Received: from hermes.local (204-195-112-131.wavecable.com. [204.195.112.131]) by smtp.gmail.com with ESMTPSA id 12-20020a170902c24c00b001c0e92d862bsm4111893plg.99.2023.09.18.11.25.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 11:25:23 -0700 (PDT) Date: Mon, 18 Sep 2023 11:25:20 -0700 From: Stephen Hemminger To: dev@dpdk.org Subject: RFC - handling kvargs options without value Message-ID: <20230918112520.4bcd72f6@hermes.local> 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 There is a problem in current devargs/kvargs code for cases where the device argument expects a value but none is given. There are a several possible ways to address the problem and would like some feedback before finalizing a fix. Options: 0 - do nothing, if no option is given but device expects one then the driver will crash dereferencing NULL. Not best user experience but if argument is needed, any error handling only just going to print error anyway. 1 - fix all the drivers. There is a patch series in patchwork already that does most of this. Downside is that it is largish patchset and not sure if everything is covered and may break with new drivers. 2 - enforce that value must be present in kvargs. Change the places where driver is not expecting a value now, to instead take 1/0 as true/false. I.e in TUN driver persist flag, make it so persist is now: persist=1. Downside is that change is visible to application startup. 3 - variation of #2. Enforce in kvargs, but let driver make exception. Add special character to the keys for the case of presence option. I.e in TUN driver persist flag, set "persist:" and make : be indicator that no value is expected. Downside is that it is an API change, that may break applications using kvargs. But I doubt that any external apps would use this API anyway. 4. - add new richer api for parsing. Introduce rte_kvargs_getopt() which takes a structure with three value flag similar to getopt_long for required_argument, no_argument, optional_argument. Replace all usage of old API rte_kvargs_parse() , and deprecate it. This is the most complete change. But requires modifying lots places that call rte_kvargs_parse(). 5. - change rte_kvargs_parse() to take option structure and version the API. same as #4 but keep the same function name. Have a start on Option 4. But doing 3 seems easiest.