Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp809553ybl; Fri, 10 Jan 2020 07:06:17 -0800 (PST) X-Google-Smtp-Source: APXvYqzMqxqmiCJoynM0fhJpNF5WuUFdq+OEGMp8gK7ReuPkTFV1I3YsByFw69t5sAA0rCMHs8hL X-Received: by 2002:a9d:1c95:: with SMTP id l21mr2909062ota.271.1578668777322; Fri, 10 Jan 2020 07:06:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578668777; cv=none; d=google.com; s=arc-20160816; b=QeLA0SQu7A/Ah8LUTK31PesIPyiLkKwciWLfKm40KuwFce6dQLKD63jPn57yTRp/OK m864Y/b1EsqLqH4lC/hwW4FVOu1HQSV4FpScL+XOfcko27VnZLW3jsnsvCLMKungBlt4 CwWNho5CgAAuuyprl1KNqOzqJ49p4rJrTrapQtIO5frE21PnTZ9yD17m9OX7+O53wvkX LesWNzes8aJmmTisvg9o7PGn/saE7D+EV5kRx4edsoT/d9aFamsq/lMh5KsdMWPYZJxh iPRCmHRrmCF0XXDQeTeQIwCWS1jfKaFCXbwB7uKZeWZ0MM14frOiwLp5HvTIuUXmQNKq WIcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=zpRs+t3MnBquJOXxU7DLw4h9hLZJR04RmfH2UeDCZ2w=; b=qXBmRYnaonfHmYJ9FmXDQJiz1Tp3cZBS+AqTcD5rGSmTP2uN/J9g/eWVrftaNZw9QP 5JVH5NZv36LlC8r2AJom0p/0166uYfs48cLnMvg4jsttuaBzlJELeJxV1xZk6PmeWDHe D5j7/eZbraw2zF7gfw05L5qAQ5L3YZrJJTqPak/xAe+i4Zsm8mFdMHKuXXOJZCNW8byc O7bBN8jVs4tp2SYQuyY5p5mgMaDTK8Uf/DiDWxu3/I/AtBzsJ4lzaP2FZa0tSoqk1v+r cCiWbnO8FSvR5q2u3gYdyyXKjG8ylE87KOepI6CcsZiDrovG3FzTAQPQ/87w6ONReKUV z4yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mj5DUC60; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a9si1189439oid.132.2020.01.10.07.05.59; Fri, 10 Jan 2020 07:06:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mj5DUC60; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728408AbgAJPEZ (ORCPT + 99 others); Fri, 10 Jan 2020 10:04:25 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:46035 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728167AbgAJPEX (ORCPT ); Fri, 10 Jan 2020 10:04:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578668662; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zpRs+t3MnBquJOXxU7DLw4h9hLZJR04RmfH2UeDCZ2w=; b=Mj5DUC60G6wm7gMuAzjujeUPCS6yyssSlFzqlYPQ833QkECPIjhyi1LoM748DNTD5HQvrH h8xKFb6d+u/+Y0z/XQTNUxoC7GwhcI0JXJt/KVqbGz7EPZRgW6/nXcuic6ITlKNVcx/gb8 lMBr5yZuxxb9DJrqnzNpQm5FsYrCsqs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-375-fmVMeFvvMLOECcXhOOR0wA-1; Fri, 10 Jan 2020 10:04:19 -0500 X-MC-Unique: fmVMeFvvMLOECcXhOOR0wA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D8CC4107ACC5; Fri, 10 Jan 2020 15:04:16 +0000 (UTC) Received: from krava (ovpn-205-164.brq.redhat.com [10.40.205.164]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E9F628088C; Fri, 10 Jan 2020 15:04:12 +0000 (UTC) Date: Fri, 10 Jan 2020 16:04:10 +0100 From: Jiri Olsa To: Mathieu Poirier Cc: Leo Yan , Arnaldo Carvalho de Melo , Jiri Olsa , Suzuki K Poulose , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Namhyung Kim , Ian Rogers , Adrian Hunter , Thomas Gleixner , Andi Kleen , linux-arm-kernel , Linux Kernel Mailing List , Mike Leach Subject: Re: [PATCH v4 1/2] perf parse: Refactor struct perf_evsel_config_term Message-ID: <20200110150410.GG82989@krava> References: <20200108142010.11269-1-leo.yan@linaro.org> <20200109050753.GA24741@leoy-ThinkPad-X240s> <20200109163424.GA5721@xps15> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200109163424.GA5721@xps15> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 09, 2020 at 09:34:24AM -0700, Mathieu Poirier wrote: SNIP > > If we are to deal with all flields of the union, I think it should be as below: > > union { > bool cfg_bool; > int cfg_int; > unsigned long cfg_ulong; > u32 cfg_u32; > char *cfg_str; > } val; > > But just dealing with the "char *" as below would also be fine with me: > > union { > u64 period; > u64 freq; > bool time; > u64 stack_user; > int max_stack; > bool inherit; > bool overwrite; > unsigned long max_events; > bool percore; > bool aux_output; > u32 aux_sample_size; > u64 cfg_chg; > u64 num; > char *str; > } val; > > > > > struct perf_evsel_config_term { > > struct list_head list; > > enum evsel_term_type type; > > union { > > u64 period; > > u64 freq; > > bool time; > > char *callgraph; > > char *drv_cfg; > > u64 stack_user; > > int max_stack; > > bool inherit; > > bool overwrite; > > char *branch; > > unsigned long max_events; > > bool percore; > > bool aux_output; > > u32 aux_sample_size; > > u64 cfg_chg; > > + u64 num; > > + char *str; > > } val; > > bool weak; > > }; > > > > > I will let Jiri make the > > > final call but if we are to proceed this way I think we should have a > > > member per type to avoid casting issues. > > > > Yeah, let's see what's Jiri thinking. > > > > Just note, with this change, I don't see any casting warning or errors > > when built perf on arm64/arm32. > > At this time you may not, but they will happen and it will be very hard to > debug. hi, sry for late reply.. I think ;-) we should either add all different types to the union or just add 'str' pointer to handle strings correctly.. which seems better, because it's less changes and there's no real issue that would need that other bigger change jirka