Programming

hello all,
i'm a beginner in linux programming. I need to know what is the difference between system calls and normal functions like fopen, fread etc in C?Also how to set permissions by using open system call?

If i am not wrong the system call u talking about should be shell programming? As for the set permissions are u toking about file permissions(Read write execute). Give more information if not it hard for people to knw what you trying to say =)

A regular function runs mostly in user space, and usually has a consistent interface across platforms (eg. the printf function takes the same arguments on Windows, AIX, Linux, BSD, MacOS, ...)
A system call, however, is the direct interface to the kernel functions. These are usually called by the C library as part of a regular function, and involve (as far as I know) triggering an interrupt. They are, by definition, very closely tied to the kernel, and not really that portable.

System calls are fundamental, there's no deeper to go. Trace it with a debugger and you can't trace inside open(), because the program doesn't run open -- just tells the kernel to do so. The kernel just stops the program until it's finished.

fopen/fread/fclose are all just library functions inside libc. If they were built with debugging info, you could trace them. In the end, they use open/read/close like anything else which does file I/O.

To give permissions to open, you do open("filename", O_RDWR, 0666); where 0666 are octal permissions just like UNIX file attributes. They only matter when creating the file.

chmod() also is used to change permissions.

Depending on the UNIX, the standard system calls (ones required by POSIX standards)
all present the same interface for us to call. All open() calls present the same semantics for us to use, for example, on any standards conforming system. As long as the UNIX follows POSIX standards your code is portable.

What happens inside the call is never standard. Some UNIX implementions have a list of "syscalls" with entry points (function pointers). If you understand how those entry points work, you can call them directly - which you should only do in very clearly defined cases, such as system programming just for that OS and just for that version of the OS. Other systems do not support the idea of syscalls.

Then there is the system API. This is stuff which is specific to a particular OS. So it can't be used on another kinds of UNIX. Linux has loads of these. All UNIXes have them.
Sometimes these specific calls will "piggyback" on standard calls by adding extra flags or options. ioctl() often does this. So if you know everything about ioctl on HPUX, when you get to Linux there are some new things to learn.

An example of an altogether different function is Solaris' ustat(). Solaris also has seemingly odd "devices" like doors, that some other systems have not had up until now, so ioctl has to support them on Solaris. Linux had a door implementation, which I think is now deprecated. BTW all devices on a UNIX box are presented as files. No matter how odd the device might be, so there has to be a way to play with them.

One big important exception to this is network interfaces.

I don't get your point, network interfaces (sockets) are directly associated with file descriptors, at least in all of the boxes I've seen. Ditto eth0:, bge0:, etc., (nics) or whatever you call yours.

eth0: requires ifconfig because you are configuring a driver that subsequently talks to loads of other drivers: vhscsi, fp, etc.

If you are crazy, or on Linux you can call ioctl() on eth0:. Why? because ioctl works on files. You do Linux: try this -

Controlling Hardware with ioctls | Linux Journal