I know the function to create socket:int socket(int domain, int type, int protocol); is located in #include <sys/socket.h> and I can find it on my linux file system.
But where I can find the implementation of this function? I couldn't find a matching one in the kernel source.
Look on kernel.org for the authentic kernel source. Understand that socket(2) is one of the many syscalls(2) (you need to understand precisely what system calls are) so it is implemented inside the kernel as sys_socket and/or sys_socketcall and/or do_socket; sockets and network code are an entire subsystem (net/) of the kernel, so see its net/socket.c, etc etc... See also socketcall(2)
Application user-side code are simply issuing a syscall, so socket(2) is a thin wrapper around a system call (in GNU libc or musl-libc or whatever implementation of the C standard library you are using). See also this.
sys/socket.h should be in /usr/include. Typically, it's a part of the "GNU C Library", but depending on your system, that might also be a different C library (ie. on systems you can't call GNU/Linux, like Android, there might be different libc than glibc).
However, that's just the header, not the implementation of the syscalls beneath! You will have to look through glibc's source code (which usually is not installed, only the headers), and then match what you find there to the system calls implementation in linux.
if you want to check the linux implementation of socket creation, you. can look here
Related
Sometimes, I want to know the implementation of a c function. My editor is vim. I have try ctags and cscope, and man.
man 2|3 only tell me how to use a function.
Both ctags and cscope can just find some of the implementation of functions.
They all can't find some functions. especially some system function(calls).
If a function can be use by include some header file, is there any way easily find the implementation of a function,
select(2) is a system call (but I suggest using poll(2) instead - google for C10K problem to understand why I prefer poll over select). So it is really implemented inside the linux kernel. The libc contains a small stub function (translating the C argument convention to the syscall convention, then doing the real syscall with e.g. some SYSENTER machine instruction). You could look into the source code of MUSL Libc (I recommend MUSL libc because its source is much easier to read) or the real Gnu libc to see that wrapper function.
FD_SET is just a macro, defined in /usr/include/x86_64-linux-gnu/sys/select.h and really in /usr/include/bits/select.h
But you are very right to try to find out how software functions of Linux are implemented: take advantage that it is free software.
Actually, the syscall layer is well defined and quite stable (see the syscalls(2) man page, and read Advanced Linux Programming for more. Look also for the Posix standards). It is much more interesting to study the source code of higher-level libraries using them (e.g. Qt, Gtk, ...).
From an application's point of view, syscalls are elementary "atomic" operations. strace is a handy utility to find which syscalls are done by some process (or running program).
You won't get around pulling in the sources of the module providing the function's implementation.
For Linux most of the modules in use are open source, so access to the sources shall be possible.
Where to get the sources from depends on library and/or the distribution in use. This includes the kernel.
There are distributions which may include all sources. Gentoo is one of those.
For Debian based distros it is easy to pull a package's sources using the apt-get tool:
$ apt-get source <package-name>
Other distros may use other ways to provide sources. Perhaps fellow SO experts might like to comment/answer regarding those.
I have a C program which contains #include <dos.h> header. It shows a compile time error. I know that the dos.h header file is not valid in Linux.
Is there any other equivalent header for dos.h in Linux?
Linux is a Posix/Unix like system, so you should learn the system calls and facilities that you can use. Read the advanced unix programming book (or some equivalent; AUP is considered a very good book). You can also read advanced linux programming (even online, a copy is here). So Linux don't have a dos.h header.
You could also type man 2 intro to get an intro to syscalls, and their list in in syscalls(2) man page. From an application's point of view syscalls are elementary operations provided by the Linux kernel.
The GNU libc provides a big lot of functionality (e.g. standard C functions like malloc and fprintf, and system functions like fgetpwent to query user database, etc etc...) above the system calls. Almost every Linux program uses it.
If you care about coding stuff which should be portably runnable (after recompilation) on other similar systems (e.g. MacOSX or FreeBSD) consider following the Posix standard.
If you want to code a terminal screen application, consider using ncurses.
If you care about graphical interfaces, use a graphical toolkit like Qt or Gtk; they usually interact with an X11 server (and both Qt and Gtk are able to run on some other non Posix systems, e.g. Windows, by providing a common graphical abstraction layer.). Both Gtk and Qt are adding an abstraction layer (Glib and QCore respectively) above system functions and facilities (in particular above the pthreads standard thread library).
At last, Linux is free software; so you might find interesting to look inside the source code (of a library or utility) that you are using. You could even improve it and contribute to it.
In all these aspects, Linux programming is very different from Windows or DOS.
Don't try to mimic every Windows or Dos function into Linux (e.g. don't ask the equivalent of every dos.h function); learn the Posix/Unix way of thinking and coding.
The time(7) man page tells you a lot about time (various meanings and functions about it) on Linux.
Don't forget to ask warnings from the compiler with gcc -Wall -Wextra; as a general rule, improve your source code till you get no warnings.
There cannot be an exact Linux equivalent of dos.h because Linux (i.e. Unix or Posix spec) and Windows are systems with different features and concepts. However several free libraries (I mentioned Glib and QCore) are providing common abstractions to fit into Linux and into Windows, so if you want to develop software portable to Windows and to Linux I suggest using these libraries instead (use them both on Windows and on Linux).
(I also suspect that Microsoft would use legal threats -patent or copyright based- to avoid that free clone of their proprietary dos.h, given their monopolistic reputation and their aversion to standards and to free software; I admit I have strong opinions against Microsoft..)
dos.h header file is interface to the DOS operating system. They are not portable to operating systems other than DOS (means not works in Linux). Which functionality in dos.h you are going to use?
#include<dos.h> is not available for Linux
but if you want to use dos.h for displaying the time you can use the system function and do it like this
prototype -> system(command);
system("date +%H:%M:%S");
if you want your program to sleep for a specific seconds
try this
system("sleep 3") //sleep for a 3 seconds
or use this
std::this_thread::sleep_for(std::chrono::milliseconds(100));
but you have to include the thread header file #include<thread>
I am learning network programming through the sample source codes from this link http://cs.baylor.edu/~donahoo/practical/CSockets/textcode.html. During the compilation, just wondering why in Solaris environment, i have to manually link socket and nsl library in the make file but when in the linux machine, i dont need to do that ?
Documentation used: http://developers.sun.com/solaris/articles/solaris_linux_app.html
This is because linux's libc, the glibc (-lc, which is linked by default to all programs) includes socket part of POSIX; and nis/nis+ dynamic libraries in linux are loaded dynamically by libc too.
But in Solaris, there are a lot of libraries with basic functionality, which are not in libc.
(libc, libucb, libmalloc, libsocket, libxnet, etc). I think, it was a design solution to allow user link only parts of API he needs.
In linux there are some basic libraries outside libc too: libaio, librt, libm.
With separate library it is easier to update only some parts of system; and it is possible to have several implementations (e.g. to provide greater compatibility/workarounds with older versions of UNIX) of some libraries coexisting in same system.
This question is discussed a lot, e.g. http://web.archiveorange.com/archive/v/KcxCHdLNpD6NANxmAt3b http://mail.opensolaris.org/pipermail/opensolaris-code/2007-January/010316.html
are seriously considering folding libnsl and libsocket into libc.
It would be nice to move ONLY the current POSIX-based and other
standards-based functionality (Unix98 etc.) libnsl+libsocket functions
to libc and keep all the compatibilty-wrapper stuff in libnsl/libsocket
to avoid that libc gets bloated with 20years of Unix
backwards-compatibility workarounds
Because in Linux, the entire networking API is implemented in libc.so which is linked into every C program by default, while in Solaris, its implemented in separate libraries.
I am using a custom user space environment that has barely no OS support: only one char device, mass storage interface and a single network socket.
To provide C programming to this platform, I need a libc. Is there any libc project that is configurable enough so that I can map low-level IO to the small API I have access to ?
AFAIK glibc and uclibc are expecting linux syscalls, so I can't use them (without trying to emulate linux syscalls, which is something I prefer to avoid).
There are several different libc's to choose from, but all will need some work to integrate into your system.
uClibc has a list of other C libraries.
The most interesting ones on that list are probably
dietlibc
newlib
FreeDOS has a LIBC
EGLIBC might be simpler to port than the "standard" glibc.
newlib might serve this purpose.
I've wanted to write a kernel for some time now. I already have a sufficient knowledge of C and I've dabbled in x86 Assembler. You see, I've wanted to write a kernel that is POSIX-compliant in C so that *NIX applications can be potentially ported to my OS, but I haven't found many resources on standard POSIX kernel functions. I have found resources on the filesystem structure, environment variables, and more on the Open Group's POSIX page.
Unfortunately, I haven't found anything explaining what calls and kernel functions a POSIX-compliant kernel must have (in other words, what kind of internal structure must a kernel have to comply with POSIX). If anyone could find that information, please tell me.
POSIX doesn't define the internal structure of the kernel, the kernel-to-userspace interface, or even libc, at all. Indeed, even Windows has a POSIX-compliant subsystem. Just make sure the POSIX interfaces defined at your link there work somehow. Note, however, that POSIX does not require anything to be implemented specifically in the kernel - you can implement things in the C library using simpler kernel interfaces of your own design where possible, if you prefer.
It just so happens that a lot of the POSIX compliant OSes (BSD, Linux, etc) have a fairly close relationship between many of those calls and the kernel layer, but there are exceptions. For example, on Linux, a write() call is a direct syscall, invoking a sys_write() function in the kernel. However on Windows, write() is implemented in a POSIX support DLL, which translates the file descriptor to a NT handle and calls NtWriteFile() to service it, which in turn invokes a corresponding system call in ntoskrnl.exe. So you have a lot of freedom in how to do things - which makes things harder, if anything :)
The opengroup.org leaves the decisions about kernel syscalls to each implmentation.
write(), for example has to look and behave as stated, but what it calls underneath is not defined. A lot of calls like write, read, lseek are free to call whatever entrypoint they want inside the kernel.
So, no, there really is nothing that says you have to have a certain function name with a defined set of semantics available in the kernel. It just has to available in the C runtime library.