I'm trying to add new System Call to Linux Kernel(x86_64). Based on this article which explained how to add System Call to Kernel(x86). The article says I need to define my System Call name in a file called syscall_table_32.S which is located in src/arch/x86/syscall_table_32.S.
But in my case, there is no file named syscall_table_32.S or syscall_table_64.S in the kernel source! There isn't even a directory for x64 System Call table in src/arch/.
So, where is syscall_table_64.S defined in kernel 3.13.0-14-generic (x86_64) ?
Where can I define a new system call?
Version 3.3 onward are different from 2.X that the guide use. You should look for the syscalls directory, in the arch/x86/ directory. So is:
cd /kernel-src/arch/x86/syscalls/syscall_64.tbl
kernel-src being the directory where your kernel sources resides. A good idea would be reading this answer in SO and compare it with your resource.
Related
I know this might be a stupid question.
I know that make tests for file changes based on the timestamp of a dependency and if it's newer than a target.
1) Does make use stat?
2) Information for stat is stored somewhere on the filesystem, correct?
The answer to both your questions is "yes". The last modification time is an attribute of every file (and directory) and is maintained by the filesystem (it's part of the directory entry on most filesystems but that's not a requirement).
The way this data is accessed is via the stat(2) call (at least on POSIX systems; on Windows stat() exists but is a helper function translating to Windows native calls underneath).
I want to read the file properties like File Description , Product name , Copyright of a exe file. Is there any Windows API for it?
Yes. It may not be evident to find it because the Version Information chapter is hidden below Menus and other Resources. The rationale for that is that it is stored is the executable files (including DLL) as a VERSIONINFO resource that was originally intented to help install tools to know whether the version to install was more recent than an existing version.
You will find examples for using it in the linked page to the MSDN and also in SO in different places, for example here
Those values are stored in the file's version info resource. You can use GetFileVersionInfo() and VerQueryValue() to read them.
This a certainly a dumb question, but when I look at the sources of the linux kernel of raspberry pi (here : https://github.com/raspberrypi/linux), this is not the same as the root organisation (that you can find here : http://labor-liber.org/en/gnu-linux/introduction/tree). However, there are some similarities (ex : usr repository).
Do someone know why?
Thank you!
Kernel sources are files for build the kernel. Usually, these files are located in some directory. After building (and installing) sources can be safetly cleaned.
Root directory is the top-level directory for working OS.
Most of subdirectory names common between between kernel sources and root directory are just accidental coincidence.
First link only contains the kernel source code; which you need to compile and then you can replace the kernel image and modules on the target.
While the second link shows the filesystem tree; it means how the files and directories are organised in the linux.
In some cases (depend upon the type of flashed OS ) you can see your kernel source code (which you have mentioned in the first link) in your running OS as well inside the /usr/src/<kerne_path> directory.
On Windows, Stack uses %AppData/stack as its storage directory by default. Is there a way to change that? I've only managed to move executables (by setting local-bin-path in the global config.yaml file), but I'd like all GHC versions, compiled packages, etc. to be stored somewhere else.
This isn't currently supported, but it should be fairly straightforward to add. I've added a ticket for it here: https://github.com/commercialhaskell/stack/issues/2067
The relevant code is here https://github.com/commercialhaskell/stack/blob/6f7871b893de2792ad9b9a02d934dfa72f8d9090/src/Stack/Config.hs#L266
The DLL lookup path, as described in MSDN is:
The directory where the executable module for the current process is located.
The current directory.
The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
The directories listed in the PATH environment variable.
Which brings up the following doubt:
Suppose I have an executable in some directory, say: c:\execdir\myexe.exe and it loads a DLL that's found in PATH and is located in c:\dlldir\mydll.dll. Now, suppose mydll.dll tries to load another DLL with LoadLibrary. Which directory will be looked at first - c:\dlldir or c:\execdir?
I think that the lookup rules quoted above say it's going to be c:\execdir because that's allegedly "the directory where the executable module for the current process is located", but it would be nice to get a confirmation from another source.
EDIT: Also, is c:\dlldir\ looked at at all? After all, it's neither where the .exe is located, nor the "current directory" (if that is meant in the general sense).
P.S. I'm interested in both Windows XP and 7.
Yes, it is the executable directory first and it was realised this could lead to a security vulnerability under certain circumstances. There is advice on that page for ensuring your application is not compromised via this mechanism.