From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B0C01C3DA5D for ; Thu, 25 Jul 2024 06:29:17 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.764657.1175144 (Exim 4.92) (envelope-from ) id 1sWryO-0006oQ-Ab; Thu, 25 Jul 2024 06:29:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 764657.1175144; Thu, 25 Jul 2024 06:29:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sWryO-0006oJ-8A; Thu, 25 Jul 2024 06:29:08 +0000 Received: by outflank-mailman (input) for mailman id 764657; Thu, 25 Jul 2024 06:29:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sWryN-0006oA-Kt for xen-devel@lists.xenproject.org; Thu, 25 Jul 2024 06:29:07 +0000 Received: from sonata.ens-lyon.org (domu-toccata.ens-lyon.fr [140.77.166.138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2f84e0e2-4a4f-11ef-8776-851b0ebba9a2; Thu, 25 Jul 2024 08:29:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id 02667A0304; Thu, 25 Jul 2024 08:29:03 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtxuR0i-bsvf; Thu, 25 Jul 2024 08:29:02 +0200 (CEST) Received: from begin (aamiens-653-1-111-57.w83-192.abo.wanadoo.fr [83.192.234.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id B859CA02C4; Thu, 25 Jul 2024 08:29:02 +0200 (CEST) Received: from samy by begin with local (Exim 4.98-RC3) (envelope-from ) id 1sWryI-000000003Vp-1Ko8; Thu, 25 Jul 2024 08:29:02 +0200 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f84e0e2-4a4f-11ef-8776-851b0ebba9a2 Date: Thu, 25 Jul 2024 08:29:02 +0200 From: Samuel Thibault To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, wl@xen.org Subject: Re: [PATCH 4/4] mini-os: remove sanity_check() Message-ID: <20240725062902.croun5gpmgfplfyt@begin> Mail-Followup-To: Samuel Thibault , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, wl@xen.org References: <20240722150141.31391-1-jgross@suse.com> <20240722150141.31391-5-jgross@suse.com> <20240722213544.hjyohnoz4mtcfltr@begin> <884d746c-47e4-4d0f-87a9-e2a03d2a3286@suse.com> <20240724224431.jelemlo6tt2jgaw2@begin> <7b76ceae-181d-4371-8feb-195fd4cc6d90@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7b76ceae-181d-4371-8feb-195fd4cc6d90@suse.com> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) Jürgen Groß, le jeu. 25 juil. 2024 08:25:18 +0200, a ecrit: > On 25.07.24 00:44, Samuel Thibault wrote: > > Hello, > > > > Jürgen Groß, le mar. 23 juil. 2024 08:36:13 +0200, a ecrit: > > > On 22.07.24 23:35, Samuel Thibault wrote: > > > > Juergen Gross, le lun. 22 juil. 2024 17:01:41 +0200, a ecrit: > > > > > Remove the sanity_check() function, as it is used nowhere. > > > > > > > > > > Since any application linked with Mini-OS can't call sanity_check() > > > > > either (there is no EXPORT_SYMBOL for it), there is zero chance of > > > > > breaking any use case. > > > > > > > > Don't we still want to keep it around, at least as formal documentation > > > > of the expected status of the list? > > > > > > Hmm, is it really worth the extra code? > > > > I have already seen such kind of piece of code getting very convenient > > when tracking odd bugs. > > What about putting it under CONFIG_TEST then? Ok ! Samuel