[GSoC] universal list of syscalls
Hi My name is Edson Ticona. I was planning to participate in gsoc for strace in a project related to multiarch support, and they suggested me to check for this post http://thread.gmane.org/gmane.linux.kernel.cross-arch/21821 in the linux-arch mailing list so I think it might be better to help in the kernel as it would be useful not just to strace. What I have done so far is to write a system call for some architectures (x86, arm, sparc and microblaze) in order to understand how this part of the kernel works. I am doing the test with qemu. The post is pretty clear so maybe I could work in those archs and the tools for user space to expose this. Since this is not in any ideas list I would like some feedback and ask if someone could mentor this project. Cheers Edson
On Tue, 18 Mar 2014 09:00:51 -0500, Edson Ticona said:
What I have done so far is to write a system call for some architectures (x86, arm, sparc and microblaze) in order to understand how this part of the kernel works.
That's a good learning project. However, GSOC is about learning projects that also help the sponsor and mentors. So you'll have to explain why this system call is a Good Thing to have in the kernel. What previously lacking capability does it add to the kernel?
Hi I guess I couldn't explain myself very well. Sorry for my english, but I was doing that just to understand pretty well everything about the system calls. The project is about standardizing system calls between architectures. For example, strace has problems with aarch64 and it could handle by itself, but it is better to have something similar for all archs so that the problem doesn't have to be fixed for each arch in each program, so this about the kernel itself. That is because each arch has its own way to work on the system call table. Hope I make things clearer On Tue, Mar 18, 2014 at 9:25 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 18 Mar 2014 09:00:51 -0500, Edson Ticona said:
What I have done so far is to write a system call for some architectures (x86, arm, sparc and microblaze) in order to understand how this part of the kernel works.
That's a good learning project. However, GSOC is about learning projects that also help the sponsor and mentors. So you'll have to explain why this system call is a Good Thing to have in the kernel. What previously lacking capability does it add to the kernel?
On Tue, 18 Mar 2014 09:48:06 -0500, Edson Ticona said:
Hi I guess I couldn't explain myself very well. Sorry for my english, but I was doing that just to understand pretty well everything about the system calls. The project is about standardizing system calls between architectures.
Good luck with that. The biggest problem is that you can't merge the architecture's syscall tables, because (for historical reasons) different archs have different numbers for various syscalls. Those are now baked into the ABI and can't be changed. So if arch A has the io_getevents() syscall as 208, and arch B has it as 213, you're stuck.... The historical reasons? Each arch tended to assign syscall numbers as each syscall was wired up. So it was possible for an arch to delay a bit wiring up a syscall that needed per-arch support, wire up some other syscalls, and then wire up the earlier syscall once the support was written. At which point all those syscalls have different numbers than other archs that wired up the one syscall earlier.
participants (2)
-
Edson Ticona -
Valdis.Kletnieks＠vt.edu