I am studying system call in linux with source code in version 2.6.39.4.
Books said that system call is implementd in entry.S, located in arch/i386/kernel/entry.S,
but I can't find that file in v2.6.39.4.
so which file implement system call in my version? Any difference with old ones?
The information in your books seems to be outdated.
You should find what you're looking for in arch/x86/kernel/entry_32.S and arch/x86/kernel/entry_64.S.
Related
I try to develop a thirdparty unixODBC driver, it is a secondary development based on the original file libodbc.so.2.0.0.
so I want to rename 'libodbc.so.2.0.0' to 'libodbc.so.2.0.0_renamed'. And soft link my dynamic library file to libodbc.so.2.0.0.
But I found an issue bothering me, when I rename native file and run 'sudo ldconfig', the file named 'libodbc.so.2' automatically linked to the renamed file 'libodbc.so.2.0.0_renamed', as below:
I could not understand that:
why it occurs;
how to appropriately replace the library.
I don't have enough ackownledge about linux, so that I failed to get any keyword to search and deal with it.
Could you help me, thank you very much!
Shared objects under GNU/Linux follow a specific version naming scheme, which is known by the loader (and OS component, actually part of libc framework) to determine if a newer library is retro-compatible with some older version to which a binary was originally linked against. By adding the renamed suffix, you are violating the convention and the dynamic linking system is getting confused. You should renamed as suggested by #Bodo above.
In addition, perhaps rather than using rename, you might consider using the very versioning scheme. From GNU Build System (aka Autotools) manual, the version cheme is like it follows:
Versioning: CURRENT:REVISION:AGE
CURRENT The latest interface implemented.
REVISION The implementation number of CURRENT (read: number of bugs fixed...)
AGE The number of interfaces implemented, minus one.
The library supports all interfaces between CURRENT − AGE and CURRENT.
If you have
not changed the interface (bug fixes) CURRENT : REVISION+1 : AGE
augmented the interface (new functions) CURRENT+1 : 0 : AGE+1
broken old interface (e.g. removed functions) CURRENT+1 : 0 : 0
Therefore a possible history of your lib might be:
1:0:0 start
1:1:0 bug fix
1:2:0 bug fix
2:0:1 new function
2:1:1 bug fix
2:2:1 bug fix
3:0:0 broke api
3:1:0 bug fix
4:1:1 bug fix
5:0:0 broke api
You might, for instance, call the older and newer versions of libodbc.so.x.y.z, according to your needs. Just an idea.
System calls are added to syscall_32.tbl or syscall_64.tbl but how is it being parsed. I never came across a .tbl extension while programming in C.
Assuming you are asking about x86-related files located at arch/x86/entry/syscalls, they are just passed to shell scripts syscallhdr.sh and syscalltbl.sh on the same directory, which generate C-headers on the kernel build tree
arch/x86/include/generated/uapi/asm/unistd_32.h
arch/x86/include/generated/uapi/asm/unistd_x32.h
arch/x86/include/generated/uapi/asm/unistd_64.h
and
arch/x86/include/generated/asm/syscalls_32.h
arch/x86/include/generated/asm/syscalls_x32.h
arch/x86/include/generated/asm/syscalls_64.h
respectively. Those headers are later included/used by appropriate C files.
PS: In general, you may look up such things on the Makefile's.
You can find a mention of it here: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
however without any explanation. I couldn't find information about it by googling.
What is the purpose of a .clientrc file?
As mentioned in the comments, ".clientrc" was just chosen as an example file name.
If you google site:code.visualstudio.com clientrc, that page is the only search result. And googling site:github.com/microsoft/vscode "clientrc", all the results are about example code (and most are about that example code specifically).
The .*rc file name pattern is a common convention for application-specific configuration files. There's a baeldung article on it:
Names including rc often signify files or directories of files with code. Specifically, this code consists of commands that are meant to run when a program is executed. Indeed, that program can be an application, but it can also be a whole operating system.
Because of this, the original rc affix and extension both meant “run commands”. In particular, a widely accepted source of the term is the Compatible Time-Sharing System (CTSS)
I am doing a toy project. I want to find setitimer's source code. But after I tried "whereis" command, nothing came out.
Could you help me?
Thanks!
You can find it in sys/kern/kern_time.c in the function kern_setitimer.
If you've got the kernel source installed on your system, the file is /usr/src/sys/kern/kern_time.c.
One good place to search kernel code is Robert Watson's FreeBSD and Linux Kernel Cross-Reference, which is based on LXR. Search for identifier setitimer - find it here.
I am using the POSIX call nftw() for traversing a directory structure. The directory structure is flat - only 4 files and no subdirectories.
However when I call nftw() a lot of times on this flat directory then I get an error message after a while:
"too many open file handles".
It turned out that this happens when the flag FTW_CHDIR is used.
Would you agree that it is a bug in the Linux implementation of nftw() ?
UPDATE
A fix is now available in the glibc repositories.
here are some links to the source code I have used for testing:
main.cpp: http://sourceware.org/bugzilla/attachment.cgi?id=4586&action=view
Makefile: http://sourceware.org/bugzilla/attachment.cgi?id=4587&action=view
UPDATE
MacOS-X is also hit by the bug
Solaris9, Solaris10 and AIX 5.3 do not have the bug
For me it looks like there is really something wrong with the nftw implementation on linux.
I have filed a bug report, see here
UPDATE: A fix is available in the glibc repositories now.
It has the same behaviour on Mac OS 10.6.2. So probably somehow part of the specification, though I don't see how exactly.
Regarding Mac OS: bugreport submitted to Apple as radar #7640283. (No hyperlink possible, unfortunately.)