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 8EED7A04A7; Tue, 25 Jan 2022 22:11:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6079141184; Tue, 25 Jan 2022 22:11:08 +0100 (CET) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by mails.dpdk.org (Postfix) with ESMTP id 4E70741161 for ; Tue, 25 Jan 2022 22:11:07 +0100 (CET) Received: by mail-ot1-f47.google.com with SMTP id 10-20020a9d030a000000b0059f164f4a86so10216903otv.13 for ; Tue, 25 Jan 2022 13:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7Ba1fRZAh1fwKnFenygbVuE5HV+GNpUvZ4pZsTZQJo=; b=O4uJFA4KczQGiZoIAK2cqlL0LKgNWbjCWfb0N+fOc5T5w1cR1OYOb1S1IYYzIbfEeA sKvmgdKxJfgHGlUvsr+QzI7CxGmZNem2bv3YG7U0GLr9KB7iU5kP5c9kiC8E9eQ3Fz00 WCMA+3W2QJ4fSCPLPNNh89WWJyUVqhiVnesQs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7Ba1fRZAh1fwKnFenygbVuE5HV+GNpUvZ4pZsTZQJo=; b=G4Dgszo/EirN+ZOXcZa44jkIpQRpZ+UdNwX2PHAp62YdL1izkeIEGC/+iurqkUqzme nOniJpScPVUXeq2VYUI8yjjUL+4XoAm3UP7XUz3O66h1LLHUGhUpX+vZSJvV4ySo4r9I ucJ1gpv0CDwavvPnnWt7W/coL55UgA+2o7pNUoOlZZ7s0ax5deOgMhXJw/xFaQ4Aznph bcPm+KzQNQ4hXTn5svSHnCn09zWJhVb1h/CSqnI2+KSQ4bZT4a/yn55yHtgjGeaQsshX 4m/dPo4sc0aKT+w2KXk7rBUz3NvzWfugrKoyD+TscD7wYk2K3kbfoIHJXuaLKoQ/hzua u79g== X-Gm-Message-State: AOAM533HckM4Wc/RKW0kL56Gths87ij/WyHOK+WTbg1I7Sd6BgFybRoa XbDXcW295zBiCnV2uW632HUPJYXymBiNzS829QDhMA== X-Google-Smtp-Source: ABdhPJzJGrRrWzejQ9J4LLRebXAqrTxbpXqQ7CnTdCzZKkn2Utu7vfjTk56S2piFjqKZ5SXIo7AELyaHJyIpywymLww= X-Received: by 2002:a05:6830:2045:: with SMTP id f5mr15261539otp.67.1643145066610; Tue, 25 Jan 2022 13:11:06 -0800 (PST) MIME-Version: 1.0 References: <20220125083836.2354-1-junx.dong@intel.com> <20220125083836.2354-2-junx.dong@intel.com> In-Reply-To: <20220125083836.2354-2-junx.dong@intel.com> From: Owen Hilyard Date: Tue, 25 Jan 2022 16:10:30 -0500 Message-ID: Subject: Re: [DTS][V2 1/2] framework/*: Add function to support ASan test To: DongJunX Cc: dts@dpdk.org, "Tu, Lijuan" , qingx.sun@intel.com Content-Type: multipart/alternative; boundary="0000000000000297d905d66e86df" X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org --0000000000000297d905d66e86df Content-Type: text/plain; charset="UTF-8" > > sys.path.insert(0, DTS_PATH) > Please use python modules to handle this behavior. Directly modifying the interpreter path causes issues with static analysis tools and IDEs. Also, this seems to be designed to be entirely outside of the normal flow for DTS. To me, it seems like you could do much the same thing by using setting some variable (DTS_USE_ASAN) to true, and then in the DPDKdut::build_install_dpdk_*_meson, add "-Db_sanitize=address" to the arguments for meson. After all test suites are run, but before we output results, add a check for that variable (DTS_USE_ASAN) and if it's true then check the logs from all the test suites that were run for any ASAN failure messages. If there is some reason why that isn't feasible, please let me know. Currently, this seems like an alternative entry point to DTS that will introduce an additional maintenance burden, and I think that making it instead act as a few small behavioral changes in the existing DTS framework would be easier to integrate with CI. Owen --0000000000000297d905d66e86df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
sys.path= .insert(0, DTS_PATH)

Please use python = modules to handle this behavior. Directly modifying the interpreter path ca= uses issues with static analysis tools and IDEs.=C2=A0

=
Also, this seems to be designed to be entirely outside of the normal f= low for DTS. To me, it seems like you could do much the same thing by using= setting some variable (DTS_USE_ASAN) to true, and then in the=C2=A0DPDKdut= ::build_install_dpdk_*_meson, add "-Db_sanitize=3Daddress" to the= arguments for meson. After all test suites are run, but before we output r= esults, add a check for that variable (DTS_USE_ASAN) and if it's true t= hen check the logs from=C2=A0all the test suites that were run for any ASAN= failure messages. If there is some reason why that isn't feasible, ple= ase=C2=A0let me know. Currently, this seems like an alternative entry point= to DTS that will introduce an additional maintenance=C2=A0burden, and I th= ink that making it instead act as a few small behavioral changes in the exi= sting DTS framework would be easier to integrate with CI.=C2=A0
<= br>
Owen
--0000000000000297d905d66e86df--