Is my underatanding of system calls correct? Its that programs interact with the kernel indirectly by having its opcodes interpreted by the cpu and then transferred to the system library. These opcodes (which are stored in the program's executable file) contain the instructions on what resources it needs to be able run, and the kernel provides those resources through the system's libary system calls...

Sounds good. http://wikipedia.org/wiki/System_call

You responded quickly and rephrased the question a bit, I apologize

No need to apologize! I liked the question! I found another link and added it to my collection
So I (&others someday) thank you!
https://www.cs.fsu.edu/~lacher/cours...ay+answers.pdf See #17-18.

Yes, to put it kinda loosely (I'm sure better experts wll 'chime in')
programs can call like read(3), which calls read(2), which does an INT cpu instruction, which causes the kernel to do the 'physical' I/O.

man man will list the 8 man 'sections': (2) syscall; (3) library
man 2 intro is a good read. And man 3 intro

Feel free to ask more specifics... p.s. I edit while others 'ninja' too

EDIT: oh, I think you mean exec/fork(2): e.g. the shell does to start programs you run.
http://www.tldp.org/LDP/tlk/kernel/processes.html

I think the forking operation you mentioned is for forking processes, not nessesarily system calls..

Hmmmm... I think we're now 'diverging'... Let's try to clarify...
(I'm not good at writing, so I try to find places where others have said it much better)

>programs requests what it needs to be able run
Did you mean 'resources'? A program=process (loosely) just needs memory, then cpu (I think)
These are the other functions=actions (loosely) that the kernel can do, for pgms:
http://wikipedia.org/wiki/System_cal...f_system_calls (I/O, IPC)

>the library reads the program's opcodes?
Not 'opcodes': arguments=parameters=details (loosely) on what specifically the pgm wants.

Let me [us] know...

Its my understanding that a program is anything that contains executable code. But reguarding opcodes they are basically machine code stored in a programs executable file that the cpu interprets as instructions on what the program needs done, and the cpu directs those instructions to the appropriate location on the data path in the cpu (I think)... Depending on the program they require resources such as access to certain files or ports etc..

That's a reasonable definition. Note that this executable code might be directly executable by the CPU or require an interpreter to be run.
Yes. Opcodes are low level instructions, i.e. one or more bytes defining what the CPU need to do. They are often followed by operands.
It is unclear what you mean here.

Back to your original question, system calls are basically special library functions that when called do temporarily switch a process thread from userland mode to kernel mode. Each system call perform a specific operation and when done, returns a status and possibly data to the caller.

Thanks for your response jlliagre I actually understand what system calls are/do (kind of a misleading title now that I think of it), but you made my understanding a little more clear anyhow.. But im actually trying to understand the exact steps of how all this occurs. Like a detailed 123 steps here's what happens when a program needs something.

opcode "is the portion of a machine language instruction that specifies the operation to be performed. Beside the opcode itself, most instructions also specify the data they will process, in the form of operands."

A pgm/code can do 'user mode' code=instructions, but not I/O etc 'privileged' instructions. A syscall(2) uses the INT 'opcode' to get the kernel to handle the privileged action. Here's something I found that does a good job of explaining "Interrupts and System Calls", on page 4.
http://www.cs.kun.nl/J.Hooman/DES/LinuxBasics.pdf
Much deeper details here: http://users.cms.caltech.edu/~donnie...CS124Lec14.pdf

Look into ltrace/strace. You 'could' write an assembly-language (machine code) pgm that does the same as the user-mode syscall(2), including the INT instruction! But 'library' functions make it easier.
For example, a Java/... 'draw button' calls a Java lib fcn, which may call some graphics lib fcns, which would make lots of calls to another layer of lib fcns, which would make lots of write syscalls to the kernel, for the kernel to pass on to the video driver, to do the actual hwd Output instructions to the video card, to put it loosely... You'd have to write/do many thousands of machine/assembly instructions, without all the 'library functions'.
It's all "user mode", until the syscall does the INT, to get the kernel to do the desired privileged function (I/O cpu instructions). The mode transition is where the write(2)(...pixels...) does an INT, which the kernel catches, and passes the (...pixels...) args to write fcn *INside the kernel code*, which calls the driver code, which does the I/O instructions.

Whew... Now lets hear a 'guru' explain it much better Oh, we did, while I was trying to ramble/mumble all this!

So INT handles the privileged operations, cool didnt know that.. Yeah tho I saw a video where they show you can use strace, ftrace, and perf to see how the kernel and programs interact, and recently I saw theres now Dtrace avaliable on linux.. But to actually write your own micro kernel i guess would take alot of manual code as I think you stated..

INT/trap causes a 'hardware interrupt', which turns/'hwd-jumps' cpu control to kernel code.
So, the user-mode code stops there (temporarily, until the kernel re-dispatches it), until the priv fcn is done.

"A trap usually results in a switch to kernel mode, wherein the operating system performs some action before returning control to the originating process"

Maybe that 'magic' will make it all make more sense!

Great to see you digging all the way down into understanding all this!

1 members found this post helpful.

So basically INT/trap switces the cpu into kernel mode which allows the cpu to execute any I/O operation (usually I take it priviledged operations).. And userland operations are done solely in userland mode through the instructions of basic pgm/code of the programs... Sweet learn something new everyday!

Not quite... it switches cpu from running user-mode code to kernel-mode code.
The kernel is 'just' a pgm too! Like you are processing state tax instructions,
and a state instruction 'interrupts' you, to go process the federal tax instructions.
There's only 1 you=cpu, but user=state and kernel=federal instructions to 'do'.
Loose, but ...

Yeah i edited my post before you replied lol, I figured that out. I noticed my mistake when I realized how could kernel do anything without a processer...And good analogy tho btw makes sense!