during file handling using c on red hat we need to include headers such as unistd.h,fcntl.h,sys/type.h etc ....then only we can use func like open,close,write,read....ARE THESE FUNC DIRECT SYSTEM CALLS OR ARE THEY DEFINED IN ABOVE LIBRARIES OF C IN WHICH ACTUAL SYSTEM CALLS ARE MADE ?????
for the later case if possible also give the probable system calls in the definition...
for former case if they r system calls why we need to include headers in c prog.

similarly....is pthread_create under pthread.h lib. system call or again a func defined in above lib????

and what about fork in c prog on red hat

I don't know what is it that you are exactly asking.

Every function that you use in a C program is defined elsewhere in a .h file, and present in a library which was compiled from a regular .c containing the source code, against which your program will link (might it be a standard C lib or a 3rd party library).

Whether this functions will be complicated C functions to do something, or wrappers to a more low level system thing is up to the concrete function and the implementation. You would need to look at the concrete piece of course code to know that.

Red Hat is out of the formula here. Gcc is the same under Red Hat or elsewhere.

When software designers write software (for the Unix/Linux/OSX worlds), they want it to run in as many environments as possible, and with a minimum of fuss. (Read: expen$e!)

Their software might find itself running on a Windows machine, a Macintosh, a Linux computer, an IBM Mainframe, or a ##CLASSIFIED## (no kidding...), and the designers simply want it to "just work" in all cases.

So... the software development community builds libraries that "do all sorts of useful things," and they "port" those libraries to all the various environments (including ##CLASSIFIED##) where they need to be able to "do all of these sorts of useful things."

In all of these various environments, these libraries present exactly the same, consistent, "friendly face" to every application program that comes calling. Their implementation, from one particular set of hardware to another (and from one operating system to another!) will of-course "be totally different," but the very-essential point is: because of the library, the application program does not have to care!

If the application directs all of its requests only to "the library," and is able to take for granted that "the library" exists, and that it is properly installed for whatever environment (including ##CLASSIFIED##) it happens to be running in, then ... "it 'just works.'"

And that, I assure you, saves many hair-follicles!

Remember: Linux, right out of the box, runs on more than twenty distinctly-different varieties of (non-##CLASSIFIED##...) hardware!