What are the differences bettween linux system call mmap(2) and posix mmap(3) function?
How to distinguish which one is used when broswing the source code,since they have the same header file.For details, see below.
I am running on Ubuntu.I do not think it matters what operating system you are using.The mannual page really does not supply much useful information indeed.
As per the reply of Jörg W Mittag, I think the mmap must be posix function when i am broswing the source code.But i wonder that why i need not to explicitly link to posix library when using the mmamp(3) function .I mean no extra link flag is needed when complie the source code.
As per the reply of Faschingbauer,some question arise if we make the conclusion that no posix mmap is implenmented.You see, there are some posix function implemented（eg, shm_opn、sem_open, mq_open）.In the mean time，there are corresponding ones with the same functions(eg, shmget,semget, msgget).How to explain it?At least, I think some posix functions are implemented by linux.
#log for "man 2 mmap"
MMAP(2) Linux Programmer's Manual
NAME
mmap, munmap - map or unmap files or devices into memory
SYNOPSIS
#include <sys/mman.h>
#log for "man 3 mmap"
MMAP(3POSIX) POSIX Programmer's Manual
PROLOG
This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux.
NAME
mmap — map pages of memory
SYNOPSIS
#include <sys/mman.h>
POSIX vs. Linux
First, some facts:
POSIX is a standard, made by a standards body. POSIX does not
implement anything, but rather define feature set and behavior of
interfaces. Part of this definition is a number of man pages - the
"POSIX Programmer's Manual"
Linux implements the POSIX standard, just like other UNIX
operating systems do. (I do not know if Linux is "POSIX certified",
nor do I care.) In implementing the POSIX standard, Linux takes the
freedom to extend the standard with Linux specific features; hence
it brings its own set of manual pages, the "Linux Programmer's
Manual".
Looking at the Linux ("man 2 mmap") man page, you can see that it
defines, for example, the MAP_LOCKED bit in the flags argument
(btw. MAP_LOCKED makes a separate call to mlock() unnecessary). This
flag does not appear in the POSIX man page ("man 3 mmap"), because it
is not required by the POSIX standard for a conforming implementation.
That said, there is no way to use an alternative implementation of
mmap() in Linux. If some source code that you are reading uses mmap(),
and you are on Linux, then the Linux implementation of mmap() is used, simply
because there is no POSIX implementation of it.
Respectively, the POSIX version is contained in the Linux
implementation. Linux is "compatible" with POSIX, so to say - it does
not redefine any feature required by POSIX (this would mean to violate the standard), but only adds extensions
like the MAP_LOCKED above.
Manual Pages
Hm. My personal opinion is that the POSIX version of, say, the mmap
man page is only there to confuse users. If you inadvertently hit the
section "3" mmap() man page, and you don't know what the relationship
is between POSIX and Linux, then you are indeed seriously confused at
best, or on the wrong track at worst.
I suggest you omit the section number and just say "man mmap" - this searches all the manual
sections for occurences of "mmap" and stops at the first (see "man man" for the exact definition).
(This does not work as envisioned with "man write" when you are
searching for the definition of the write() system call, because there
is a command "write" with the same same in section "1" :-) )
System Calls
As stated by "man man", manual section "2" contains system call
documentation. Knowing that mmap() is implemented by the Linux kernel
(because it is the kernel who implements core OS functionality like
memory management) can only help to clear up the confusion as to
whether the documentation you are reading is what you want.
What are the differences bettween linux system mmap(2) and posix mmap(3) function?
Section 2 documents syscalls. Section 3 documents functions. Therefore, mmap(2) is not a function at all, it is a syscall.
How to distinguish which one is used when broswing the source code?
If it is a function call, it is mmap(3). If it is a syscall, it is mmap(2). Since it is impossible to portably call syscalls from C, there will always be some sort of macro or wrapper function for the syscall.
Also, unless you are reading the source code of the runtime library for a C compiler (e.g. GCC's) or the source code of a POSIX library (such as Glibc, dietlibc, µClibc, or musl), it is highly unlikely that you will find any syscalls in the code.
But i wonder that why i need not to explicitly link to posix library when using the mmamp(3) function .
You need not link another library because mmap is contained in GLIBC; you can see this e. g. with
nm -D /lib/x86_64-linux-gnu/libc.so.6 | grep mmap
00000000000e4610 W mmap
00000000000e4610 W mmap64
I have a user-space program (Capstone). I would like to use it in FreeBSD kernel. I believe most of them have the same function name, semantics and arguments (in FreeBSD, the kernel printf is also named printf). First I built it as libcapstone.a library, and link my program with it. Since the include files are different between Linux user-space and FreeBSD kernel, the library cannot find symbols like sprintf, memset and vsnprintf. How could I make these symbols (from FreeBSD kernel) visible to libcapstone.a?
If directly including header files like <sys/systm.h> in Linux user-space source code, the errors would be like undefined type u_int or u_char, even if I add -D_BSD_SOURCE to CFLAGS.
Additionally, any other better ways to do this?
You also need ; take a look at kernel man pages, eg "man 9 printf". They list required includes at the top.
Note, however, that you're trying to do something really hard. Some basic functions (eg printf) might be there; others differ completely (eg malloc(9)), and most POSIX APIs are simply not there. You won't be able to use open(2), socket(2), or fork(2).
I am making a /proc entry for my driver. So, in the read callback function the first argument is the location into which we write the data intended for the user. I searched on how to write the data in it and i could see that everybody is using sprintf for this purpose. I am surprised to see that it works in kernel space. However this should be wrong to use a user space function in kernel space. Also i cant figure out how to write in that location without using any user space function like strcpy, sprintf, etc. I am using kernel version 3.9.10. Please suggest me how i should do this without using sprintf or any other user space function.
Most of the 'normal' user-space functions would make no sense in kernel code, so they are not available in the kernel.
However, some functions like sprintf, strcpy, or memcpy are useful in kernel code, so the kernel implements them (more or less completely) and makes them available for drivers.
See include/linux/kernel.h and string.h.
sprintf is a kernel-space function in Linux. It is totally separate from its user-space namesake and may or may not work identically to it.
Just because a function in user-space exist, it does not mean an identically named function in kernel-space cannot.
Is there any equivalent mac "bless" command in Linux. I am specifically interested in the option "--bless-folder".
No. You'll need to configure things like grub to specify where it should find your kernel, and what arguments to pass to the kernel. Quite often the arguments to the kernel would include:
root=/dev/sda1 which means the filesystem can be found on a particular partition of a particular disk;
init=/sbin/init which is the very first file the kernel executes, which loads the whole of the rest of the OS.
I am doing some simple JITing, and use VirtualProtectEx under Windows to mark pages as executable.
What would be the equivalent of that under Linux, and preferably, other POSIX/Unix-like OSes too?
You are looking for mprotect and probably also mmap. Note that, unlike with Windows, there is no way for process A to change process B's memory map (short of horrible tricks with ptrace).