On Tue, Jun 20, 2017 at 4:54 PM, Yury Norov <ynorov at caviumnetworks.com> wrote: > On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote: >> On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov <ynorov at caviumnetworks.com> wrote: >> > On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote: >> >> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote: >> > I would also notice riscv people and welcome to the discussion. >> > >> > As there is more than 1 arch that goes to be added to linux soon, >> > maybe it's better to upstream my ans James' patches separately >> > from other ilp32 patches? Arnd? >> >> Do you mean upstream those two patches slightly later? That's >> fine with me, I don't care much whether the old new stat is part >> of the syscall table for arm64-ilp32 or not, I'd leave that up to >> you, depending on whether you want to do the rework or not. > > I mean that if we want to deprecate rlimit and stat syscalls for > architectures that are under development now, it's better to upstream > patches that actually deprecate it as early as possible. Makes sense. >> I suppose the arm64-ilp32 could benefit from not having to support >> the old arm32 stat structure, but doing the new syscalls based on >> statx could delay the glibc port some more, as there are some open >> questions about how that would best be integrated. > > OK. Let's leave things as is. But then I don't see any reason to > add unxstat patch to ilp32 series if ilp32 will not disable it. Right, that's what I meant: let's leave the rlimit patch in your series as it matches the work you have already done, and is the right thing to do, and let's do the unxstat patch separately so it doesn't cause you extra work. Arnd