tequilaOS/platform_bionic
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge "Polish the syscall docs a bit more."

Browse source
This commit is contained in:
Elliott Hughes 2022-04-12 15:03:21 +00:00 committed by Gerrit Code Review
commit c635150eaf
1 changed files with 21 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
README.md
View file

@ -177,16 +177,22 @@ Adding a system call usually involves:
function was added to. Explicitly call out any Android-specific function was added to. Explicitly call out any Android-specific
changes/additions/limitations because they won't be on the man7.org page. changes/additions/limitations because they won't be on the man7.org page.
5. Add the function name to the correct section in libc/libc.map.txt. 5. Add the function name to the correct section in libc/libc.map.txt.
6. Add at least basic tests. Even a test that deliberately supplies 6. Add a basic test. Don't try to test everything; concentrate on just testing
an invalid argument helps check that we're generating the right symbol the code that's actually in *bionic*, not all the functionality that's
and have the right declaration in the header file, and that you correctly implemented in the kernel. For simple syscalls, that's just the
updated the maps in step 5. (You can use strace(1) to confirm that the auto-generated argument and return value marshalling.
correct system call is being made.) Don't try to test everything;
concentrate on just testing the *bionic* code, not the kernel. We should A trivial test that deliberately supplies an invalid argument helps check
prefer to rely on https://github.com/linux-test-project/ltp for kernel that we're generating the right symbol and have the right declaration in
testing, but you'll want to check that external/ltp contains tests for the the header file, and that the change to libc.map.txt from step 5 is
syscall you're adding. Also check that external/ltp is using the libc correct. (You can use strace(1) manually to confirm that the correct
wrapper for the syscall rather than calling it "directly" via syscall(3)! system call is being made.)
For testing the *kernel* side of things, we should prefer to rely on
https://github.com/linux-test-project/ltp for kernel testing, but you'll
want to check that external/ltp does contain tests for the syscall you're
adding. Also check that external/ltp is using the libc wrapper for the
syscall rather than calling it "directly" via syscall(3)!
Some system calls are harder than others. The most common problem is a 64-bit Some system calls are harder than others. The most common problem is a 64-bit
argument such as `off64_t` (a *pointer* to a 64-bit argument is fine, since argument such as `off64_t` (a *pointer* to a 64-bit argument is fine, since
@ -196,8 +202,11 @@ size of the thing they point to). Whenever you have a function that takes
and a foo64(), and whether they will use the same underlying system call or are and a foo64(), and whether they will use the same underlying system call or are
implemented as two different system calls. It's usually easiest to find a implemented as two different system calls. It's usually easiest to find a
similar system call and copy and paste from that. You'll definitely need to test similar system call and copy and paste from that. You'll definitely need to test
both on 32-bit and 64-bit. (These special cases usually warrant more testing both on 32-bit and 64-bit. (These special cases warrant more testing than the
than the easy cases, even if only manual testing with strace.) easy cases, even if only manual testing with strace. Sadly it isn't always
feasible to write a working test for the interesting cases -- offsets larger
than 2GiB, say -- so you may end up just writing a "meaningless" program whose
only purpose is to give you patterns to look for when run under strace(1).)
## Updating kernel header files ## Updating kernel header files