Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place! |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
10-29-2016, 11:29 PM
|
#1
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Rep: 
|
Understanding System Calls
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...
Last edited by linux4evr5581; 10-30-2016 at 03:09 AM.
|
|
|
10-29-2016, 11:32 PM
|
#2
|
Member
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
|
|
|
|
10-29-2016, 11:43 PM
|
#3
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
You responded quickly and rephrased the question a bit, I apologize
|
|
|
10-30-2016, 12:03 AM
|
#4
|
Member
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
|
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
Last edited by Jjanel; 10-30-2016 at 12:23 AM.
|
|
|
10-30-2016, 12:35 AM
|
#5
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
I think the forking operation you mentioned is for forking processes, not nessesarily system calls..
|
|
|
10-30-2016, 01:31 AM
|
#6
|
Member
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
|
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...
|
|
|
10-30-2016, 02:00 AM
|
#7
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
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..
Last edited by linux4evr5581; 10-31-2016 at 10:54 AM.
|
|
|
10-30-2016, 02:23 AM
|
#8
|
Moderator
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Debian/WSL
Posts: 9,795
|
Quote:
Originally Posted by linux4evr5581
Its my understanding that a program is anything that contains executable code.
|
That's a reasonable definition. Note that this executable code might be directly executable by the CPU or require an interpreter to be run.
Quote:
And opcodes are basically machine code that the cpu interprets as instructions on what the program does
|
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.
Quote:
and the cpu directs those instructions to the appropriate location on the data path...(I think)
|
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.
|
|
|
10-30-2016, 02:45 AM
|
#9
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
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.
Last edited by linux4evr5581; 10-30-2016 at 02:48 AM.
|
|
|
10-30-2016, 02:51 AM
|
#10
|
Member
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
|
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!
Last edited by Jjanel; 10-30-2016 at 03:03 AM.
|
|
|
10-30-2016, 03:19 AM
|
#11
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
Quote:
Originally Posted by Jjanel
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..
Last edited by linux4evr5581; 10-30-2016 at 03:21 AM.
|
|
|
10-30-2016, 03:28 AM
|
#12
|
Member
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
|
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!
Last edited by Jjanel; 10-30-2016 at 03:40 AM.
|
|
1 members found this post helpful.
|
10-30-2016, 03:35 AM
|
#13
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
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!
Last edited by linux4evr5581; 10-30-2016 at 03:55 AM.
|
|
|
10-30-2016, 03:53 AM
|
#14
|
Member
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
|
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 ... 
Last edited by Jjanel; 10-30-2016 at 03:55 AM.
|
|
|
10-30-2016, 03:57 AM
|
#15
|
Member
Registered: Sep 2016
Location: USA
Posts: 275
Original Poster
Rep: 
|
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!
Last edited by linux4evr5581; 10-30-2016 at 04:15 AM.
|
|
|
All times are GMT -5. The time now is 12:13 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|