From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de>, Rich Felker <dalias@libc.org>, "Arnaldo Carvalho de Melo" <acme@redhat.com>, lkml <linux-kernel@vger.kernel.org>, "linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>, "Jiri Olsa" <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, arcml <linux-snps-arc@lists.infradead.org> Subject: Re: perf tools build broken after v5.1-rc1 Date: Thu, 2 May 2019 10:10:15 -0700 [thread overview] Message-ID: <506c2df7-4088-9a18-91c0-c86b944714da@synopsys.com> (raw) In-Reply-To: <20190502164104.GB23984@kernel.org> On 5/2/19 9:41 AM, Arnaldo Carvalho de Melo wrote: >> While this takes care of immediate issues, for the long term, are you open to idea >> of removing the header duplicity. > > In the beginning we used the kernel headers directly, then, acting on > advice/complaints from Linus about tooling breaking when changes were > made in the kernel sources we were using directly, we moved to have > copies and notice when things change so that we could think about what > changed and act accordingly, without putting the burden to the kernel > developers to keep tools/ building, I want to keep it that way. Sure, and the reduced duplicity I propose doesn't change that in any way. The onus is still on perf maintainers to copy over any unistd changes - in the new regime, it will be just lesser since we only care about a handful of syscalls, not the entire unistd. > Now you say, validly, that there are bits that are designed to be used > by userspace, so for those, we should go back to not copying and using > it direcly, elliminating the duplicity you don't like. Indeed. > I don't know, I'm used to the duplicity and the checks, :-) > not breaking > tools even when kernel developers make mistakes in the UAPI headers, Not sure how replacing the full header with just a small hunk, out of same header out-of-line will change anything or cause any more breakage. > tools/perf is self container wrt the latest and greatest stuff not > present in older environments, and the onus is on perf developers to do > the sync. Sure it is, I'm proposing to make their work less, no more. > This specific issue here happened because I made a mistake, which I > fixed when reported, Exactly, it was a genuien mistake with a super prompt followup - your promptness is really appreciated and emulation worthy for other maintainers including myself ;-) > now I have three containers for cross building for > ARC, two versions for the uCLibc based toolchain, one for the glibc one, > libnuma, elfutils and zlib are cross build there, so should make it less > likely problems like this will happen again. Ok, well lets leave it at that for now then. >> We could use a "less evil" idiom of copying only the minimal bits (since the sync >> onus remains one way or the other) >> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects > >> #ifdef __NR_xx >> # if defined (__arch_y__) >> >> # elif defined (__arch_z__) >> >> # endif >> #endif Thx, -Vineet
WARNING: multiple messages have this Message-ID (diff)
From: Vineet.Gupta1@synopsys.com (Vineet Gupta) To: linux-snps-arc@lists.infradead.org Subject: perf tools build broken after v5.1-rc1 Date: Thu, 2 May 2019 10:10:15 -0700 [thread overview] Message-ID: <506c2df7-4088-9a18-91c0-c86b944714da@synopsys.com> (raw) In-Reply-To: <20190502164104.GB23984@kernel.org> On 5/2/19 9:41 AM, Arnaldo Carvalho de Melo wrote: >> While this takes care of immediate issues, for the long term, are you open to idea >> of removing the header duplicity. > > In the beginning we used the kernel headers directly, then, acting on > advice/complaints from Linus about tooling breaking when changes were > made in the kernel sources we were using directly, we moved to have > copies and notice when things change so that we could think about what > changed and act accordingly, without putting the burden to the kernel > developers to keep tools/ building, I want to keep it that way. Sure, and the reduced duplicity I propose doesn't change that in any way. The onus is still on perf maintainers to copy over any unistd changes - in the new regime, it will be just lesser since we only care about a handful of syscalls, not the entire unistd. > Now you say, validly, that there are bits that are designed to be used > by userspace, so for those, we should go back to not copying and using > it direcly, elliminating the duplicity you don't like. Indeed. > I don't know, I'm used to the duplicity and the checks, :-) > not breaking > tools even when kernel developers make mistakes in the UAPI headers, Not sure how replacing the full header with just a small hunk, out of same header out-of-line will change anything or cause any more breakage. > tools/perf is self container wrt the latest and greatest stuff not > present in older environments, and the onus is on perf developers to do > the sync. Sure it is, I'm proposing to make their work less, no more. > This specific issue here happened because I made a mistake, which I > fixed when reported, Exactly, it was a genuien mistake with a super prompt followup - your promptness is really appreciated and emulation worthy for other maintainers including myself ;-) > now I have three containers for cross building for > ARC, two versions for the uCLibc based toolchain, one for the glibc one, > libnuma, elfutils and zlib are cross build there, so should make it less > likely problems like this will happen again. Ok, well lets leave it at that for now then. >> We could use a "less evil" idiom of copying only the minimal bits (since the sync >> onus remains one way or the other) >> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects > >> #ifdef __NR_xx >> # if defined (__arch_y__) >> >> # elif defined (__arch_z__) >> >> # endif >> #endif Thx, -Vineet
next prev parent reply other threads:[~2019-05-02 17:10 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-19 23:32 perf tools build broken after v5.1-rc1 Vineet Gupta 2019-04-19 23:32 ` Vineet Gupta 2019-04-22 15:20 ` Arnaldo Carvalho de Melo 2019-04-22 15:20 ` Arnaldo Carvalho de Melo 2019-04-25 21:48 ` Arnaldo Carvalho de Melo 2019-04-25 21:48 ` Arnaldo Carvalho de Melo 2019-04-26 19:28 ` Arnaldo Carvalho de Melo 2019-04-26 19:28 ` Arnaldo Carvalho de Melo 2019-04-26 19:35 ` Arnaldo Carvalho de Melo 2019-04-26 19:35 ` Arnaldo Carvalho de Melo 2019-04-26 19:35 ` Arnaldo Carvalho de Melo 2019-04-29 17:23 ` Vineet Gupta 2019-04-29 17:23 ` Vineet Gupta 2019-05-03 5:58 ` [tip:perf/urgent] tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv tip-bot for Arnaldo Carvalho de Melo 2019-04-29 17:14 ` perf tools build broken after v5.1-rc1 Vineet Gupta 2019-04-29 17:14 ` Vineet Gupta 2019-04-30 1:18 ` Arnaldo Carvalho de Melo 2019-04-30 1:18 ` Arnaldo Carvalho de Melo 2019-04-30 1:18 ` Arnaldo Carvalho de Melo 2019-04-30 15:53 ` Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1) Vineet Gupta 2019-04-30 15:53 ` Vineet Gupta 2019-04-30 17:04 ` Rich Felker 2019-04-30 17:04 ` Rich Felker 2019-04-30 17:13 ` Vineet Gupta 2019-04-30 17:13 ` Vineet Gupta 2019-05-01 3:12 ` Rich Felker 2019-05-01 3:12 ` Rich Felker 2019-05-02 16:55 ` Vineet Gupta 2019-05-02 16:55 ` Vineet Gupta 2019-05-02 16:55 ` Vineet Gupta 2019-05-02 20:09 ` Arnaldo Carvalho de Melo 2019-05-02 20:09 ` Arnaldo Carvalho de Melo 2019-05-02 20:09 ` Arnaldo Carvalho de Melo 2019-05-02 16:53 ` perf tools build broken after v5.1-rc1 Vineet Gupta 2019-05-02 16:53 ` Vineet Gupta 2019-04-29 17:17 ` Vineet Gupta 2019-04-29 17:17 ` Vineet Gupta 2019-04-30 16:12 ` Arnd Bergmann 2019-04-30 16:12 ` Arnd Bergmann 2019-05-01 20:41 ` Arnaldo Carvalho de Melo 2019-05-01 20:41 ` Arnaldo Carvalho de Melo 2019-05-01 21:17 ` Vineet Gupta 2019-05-01 21:17 ` Vineet Gupta 2019-05-02 14:36 ` Arnaldo Carvalho de Melo 2019-05-02 14:36 ` Arnaldo Carvalho de Melo 2019-05-02 14:36 ` Arnaldo Carvalho de Melo 2019-05-02 15:41 ` Arnaldo Carvalho de Melo 2019-05-02 15:41 ` Arnaldo Carvalho de Melo 2019-05-02 16:09 ` Vineet Gupta 2019-05-02 16:09 ` Vineet Gupta 2019-05-02 16:09 ` Vineet Gupta 2019-05-02 16:41 ` Arnaldo Carvalho de Melo 2019-05-02 16:41 ` Arnaldo Carvalho de Melo 2019-05-02 17:10 ` Vineet Gupta [this message] 2019-05-02 17:10 ` Vineet Gupta
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=506c2df7-4088-9a18-91c0-c86b944714da@synopsys.com \ --to=vineet.gupta1@synopsys.com \ --cc=acme@redhat.com \ --cc=arnaldo.melo@gmail.com \ --cc=arnd@arndb.de \ --cc=dalias@libc.org \ --cc=jolsa@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-perf-users@vger.kernel.org \ --cc=linux-snps-arc@lists.infradead.org \ --cc=namhyung@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.