Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp3126913pxy; Sun, 25 Apr 2021 14:55:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbZbnRsrsFxH3FXFuiTWLDWrJjeKz/NRu9atXm6OuYA9FvDPUJsnvWGjfPP7E1D9R+s00T X-Received: by 2002:a17:906:b52:: with SMTP id v18mr15173057ejg.485.1619387740715; Sun, 25 Apr 2021 14:55:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619387740; cv=none; d=google.com; s=arc-20160816; b=jUzPGwWukcHoXf/IiNntI9NXhHisdMZjIMf1x+qOrMPvFldlo64XXDPGWAIavBIuq5 QZJT3IwqSec8ro5DCgfo1hHryPeB8slv04uuxZVZdTzEEdJ8phBK1475pGQbdvmR8Z8x GJnSxLxDllwFVloWcPjbkBRXCFAlCySsTF8B7Up3l0/xIg7RwT0TKeAs50GER/NIz1Ss a4NxvSFzynNj3FQR8uCmE6c1k+QM7ib/BoX4DG0KiyRdWmZJnin/pqLCYa/PWbiWe30j B03+1c7UZMGHXM405ZAlc16qtlDsKtu/5bhEJAsa194JIejOAyrobn6Aw9VUv04o3uwM /ytQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=xbQfTHU3/w2L+JNEvht3cGLem/OxkdPlOJNFy0qIAtQ=; b=iWJ+Nb7viiLiKurMG1hRve0IOPGs1kOLsuLvTtae+x98xOrAf7rJTmXTXuya5M2N6o Jxw1rKDkclRVKDps1jadEzZg8pxV8cXA8++DIa3Lx1cRT3g8pBQJKkswtKLvPM1M/t5T zxQISkwRn/ji8k7MOv1yr+dofCw50+Tmt0SqmST0ikeA6mpLHTstjkuvI4xFRbfHPmCR Vm7bLo34bo4ZYlJ36SbqbPltMkTsljHOcqg2HVwWABnzHQdslFSpB0xFjGWe4pobKmkG tppstN1MbLapK+7eMRm/xKsVNEEFCi3EJTV0dMmn4cT/x1SYsX2YxuGRyuZUAr/EqWvq 5EGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s10si12172595edw.282.2021.04.25.14.55.17; Sun, 25 Apr 2021 14:55:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231335AbhDYVzJ (ORCPT + 99 others); Sun, 25 Apr 2021 17:55:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:38872 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231231AbhDYVzI (ORCPT ); Sun, 25 Apr 2021 17:55:08 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C6B67611ED; Sun, 25 Apr 2021 21:54:27 +0000 (UTC) Date: Sun, 25 Apr 2021 17:54:26 -0400 From: Steven Rostedt To: Ed Tsai Cc: , , , , Peter Zijlstra Subject: Re: [PATCH 1/1] sched: remove the redundant 'success' in the sched tracepoint Message-ID: <20210425175426.23f292a9@oasis.local.home> In-Reply-To: <0fd8e103cc2886724979f7d93066b86b773032eb.camel@mediatek.com> References: <20210422122226.9415-1-ed.tsai@mediatek.com> <20210422114629.2b1ea3ad@gandalf.local.home> <0fd8e103cc2886724979f7d93066b86b773032eb.camel@mediatek.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 Apr 2021 08:38:22 +0800 Ed Tsai wrote: > On Thu, 2021-04-22 at 11:46 -0400, Steven Rostedt wrote: > > On Thu, 22 Apr 2021 20:22:26 +0800 > > Ed Tsai wrote: > > > > > 'success' is left here for a long time and also it is meaningless > > > for the upper user. Just remove it. > > > > Have you tested all userspace code that might use this? > > > > This is the "poster boy" example of why Peter Zijlstra hates trace > > events ;-) > > > > I know I've updated trace-cmd to check to see if this field exits > > before > > depending on it, but there may be some other tools that may not. > > Perhaps > > nothing will break. > > > > I'm all for this change, but be ware, it might be reverted if there's > > some > > tool out that that expects it to exist. This is why it hasn't been > > removed. > > > > -- Steve > > It is left here over 5 years. Old userspace code need this entry and > also someone may use it for a new tool. I hate this but it is a problem > should be resolved for the kernel or ignore just fine. > I'm willing to take this, with a note that if anyone complains, it may be reverted. But as it goes with Linus's rule about breaking user space. If you break user space, and nobody notices, you didn't really break it! -- Steve