lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 May 2019 10:10:15 -0700 From: Vineet Gupta <Vineet.Gupta1@...opsys.com> To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com> CC: Arnd Bergmann <arnd@...db.de>, Rich Felker <dalias@...c.org>, "Arnaldo Carvalho de Melo" <acme@...hat.com>, lkml <linux-kernel@...r.kernel.org>, "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>, "Jiri Olsa" <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, arcml <linux-snps-arc@...ts.infradead.org> Subject: Re: perf tools build broken after v5.1-rc1 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
Powered by blists - more mailing lists