On Tue, Nov 17, 2020 at 11:21 AM Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > ----- On Nov 17, 2020, at 1:58 PM, Peter Oskolkov posk@xxxxxxxxxx wrote: > > > My assumption here was that applications that are aware of the new API > > will always provide three parameters, while older applications will > > continue calling the syscall with two. > > > > I can't think of a situation/architecture where this will break anything. > > I think what Florian refers to here is if there would be a glibc library > wrapper exposing the system call to applications. There, the number of > arguments would matter. But it does not exist today. > > In some sense, it's a good thing that there isn't such wrapper exposed > yet. It also makes me wonder whether exposing system calls directly as a > library ABI is a good thing. It appears that library ABIs have stronger > restrictions with respect to number and types of parameters than system > calls. Technically, a library that exposes membarrier() with two parameters can just add membarrier_ex() or whatever with three parameters, not breaking anything. From the final user perspective, this would look exactly as if we added a new syscall membarrier_ex. So the question becomes whether it is better to add a new syscall and a new library function, or just add another parameter to the existing syscall, and a new library function, and the answer to this question is more about policy than about technical merits of the two approaches. I have no comments on policy matters here - this is up to maintainers. :) Thanks, Peter [...]
