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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
