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 690C745C05; Tue, 29 Oct 2024 03:51:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 291744014F; Tue, 29 Oct 2024 03:51:17 +0100 (CET) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by mails.dpdk.org (Postfix) with ESMTP id B08DF40144 for ; Tue, 29 Oct 2024 03:51:15 +0100 (CET) Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-20cf6eea3c0so40034475ad.0 for ; Mon, 28 Oct 2024 19:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1730170275; x=1730775075; darn=dpdk.org; 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=ygEDsYdjQZ5OWcYVntvqaGFVkoLa1DVsWwxHhzq86aA=; b=MoDQmT1TFF9g9lQy5j0cdfKOqKxcVRcQGc4TyUICOFLTkzi8o8whYXUulIYR4lcRKQ Mv+tQNoFyLUzyoF1Bz/SoMmhMxND2ez6gzpN1HIir6T51DKU0T/WG2LEM7fAj8DwA/+S Jg8aNvGSuVlTy2MO0EOFr+JrAHydj1V3M19h4Le+BcpO6wjxUn7HrA7Iv5TR9WVMWEM+ DJLcHUBSsB+yAOiFlQb4rGGXR+Jc5ZFUdbU2r7Ee1nSGoNm818wdIA6T7Uxk98foSGGr Rx1GlAdo6m7VArkJJmfEmeajkh5/9Zrq8uw4cMEhmMXeURPXG3t504E4E77CH5pYaEo5 j95w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730170275; x=1730775075; 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=ygEDsYdjQZ5OWcYVntvqaGFVkoLa1DVsWwxHhzq86aA=; b=qUOy8RdsTgm4OKkc02kMJpU44GtewaVgeC63YYZ8RzQSu2pk6vvDjhiblk6y+HGKDj SkBSUUGoSzIjgGxrUv2Szo1sNZX73LmFx7W0IK4plY7Kf3rgvOv0Ot5pd3MCBnVeItr+ ZV+1RmFvIxHBy8Gnj9XKPeL2RpDTVcwe5rp1i0kVMhwKH6mxTJFB/6A7hl+m++rSAR1e vsTWrpOQpMAnaPHYY50ImPjUz3+7S8QW/ICDnAlDcI4wZFeOLirJCtJH7nb4EAuwlWsd DjDmjQIblV99Vl1Cb5GoqUUaeCinn7F9epHpVYDJEmap45AQLJYZSxIp5yN/MrnQXwra qEgg== X-Forwarded-Encrypted: i=1; AJvYcCWbjG2bJ2tAbwXCgpDdUnn4MZF5zw0vMIV8pu1873HgPJCx2/Ujy3kbyvYxmIUGqP7LHnQ=@dpdk.org X-Gm-Message-State: AOJu0Yx1ZsTqW5B1kuO02kRWOs8m1O4zRQVK+aUtxxDrH9lRJYx41oZr m9HoZ/ko2W4XbWl3pEs90IPiQP1DuZ522knO+STZXagNZ8kiFwn065+5B7LtR/o= X-Google-Smtp-Source: AGHT+IEydJ5qSrnM388I15W2//1VS7jN3zWoMDb63wyuYIBmp3VIN7QEORzQr544pNR+9UE0NBWiSQ== X-Received: by 2002:a17:903:234c:b0:20c:6f6f:afe5 with SMTP id d9443c01a7336-210c6c5ce4dmr123424435ad.50.1730170274654; Mon, 28 Oct 2024 19:51:14 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bc045298sm56611535ad.261.2024.10.28.19.51.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2024 19:51:14 -0700 (PDT) Date: Mon, 28 Oct 2024 19:51:12 -0700 From: Stephen Hemminger To: fengchengwen Cc: Ferruh Yigit , Thomas Monjalon , Jie Hai , , Anatoly Burakov , Tyler Retzlaff , Amit Prakash Shukla , , Subject: Re: [PATCH v4 02/13] eal: replace strtok with reentrant version Message-ID: <20241028195112.463f4a6b@hermes.local> In-Reply-To: <74ae461a-de52-4ba4-916d-508d2d0a0746@huawei.com> References: <20231113104550.2138654-1-haijie1@huawei.com> <20241026101451.29135-1-haijie1@huawei.com> <20241026101451.29135-3-haijie1@huawei.com> <20241026200028.44b83e1b@hermes.local> <20241028083112.25b96ae1@hermes.local> <74ae461a-de52-4ba4-916d-508d2d0a0746@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 29 Oct 2024 08:56:20 +0800 fengchengwen wrote: > >>> > >>> This doesn't need to go to stable. parse_params is always single thre= aded. =20 > >> > >> I recommend replacing all, based on: > >> 1\ almost at no cost. > >> 2\ reduce analysis costs, if don't we have to analyze the callers of s= trtok when you encounter it. > >> =20 > >=20 > > Yes but. The replacement should not go to stable. > > One of the rules of stable is that changes should be minimized, and fix= es should > > not be accepted for things that can not ever happen with current code. = =20 >=20 > Hope more opinion from TB members. My assumption is that DPDK operates under similar rules as the Linux kernel. Linux kernel rules are: Rules on what kind of patches are accepted, and which ones are not, into th= e =E2=80=9C-stable=E2=80=9D tree: =E2=80=A2 It or an equivalent fix must already exist in Linux mainline = (upstream). =E2=80=A2 It must be obviously correct and tested. =E2=80=A2 It cannot be bigger than 100 lines, with context. =E2=80=A2 It must follow the=C2=A0Documentation/process/submitting-patc= hes.rst=C2=A0rules. =E2=80=A2 It must either fix a real bug that bothers people or just add= a device ID. To elaborate on the former: =E2=97=A6 It fixes a problem like an oops, a hang, data corruption,= a real security issue, a hardware quirk, a build error (but not for things= marked CONFIG_BROKEN), or some =E2=80=9Coh, that=E2=80=99s not good=E2=80= =9D issue. =E2=97=A6 Serious issues as reported by a user of a distribution ke= rnel may also be considered if they fix a notable performance or interactiv= ity issue. As these fixes are not as obvious and have a higher risk of a su= btle regression they should only be submitted by a distribution kernel main= tainer and include an addendum linking to a bugzilla entry if it exists and= additional information on the user-visible impact. =E2=97=A6 No =E2=80=9CThis could be a problem...=E2=80=9D type of t= hings like a =E2=80=9Ctheoretical race condition=E2=80=9D, unless an explan= ation of how the bug can be exploited is also provided. =E2=97=A6 No =E2=80=9Ctrivial=E2=80=9D fixes without benefit for us= ers (spelling changes, whitespace cleanups, etc).