LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
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


Reply
  Search this Thread
Old 10-31-2016, 04:03 PM   #31
linux4evr5581
Member
 
Registered: Sep 2016
Location: USA
Posts: 275

Original Poster
Rep: Reputation: Disabled

So it seems like the "queue" is actually the memory element here, and I guess it would be more accurate to say that this is an indirect multiplexed synchronistic operation between the user and the kernel. The buffers I take it are used to bridge the gap of communication between kernel and user processes. This makes sense for it to be so, for security for one, and since the kernel is of a synchronistic design. But its direct when the kernel needs to communicate errors to user land processes. Very cool

Last edited by linux4evr5581; 10-31-2016 at 04:12 PM.
 
Old 10-31-2016, 06:46 PM   #32
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178Reputation: 3178
Huh?!

It frankly seems to me that lots of people are seriously over-thinking this thing!

The Linux system (versus other operating systems ...) tries rather hard not to be "too clever." It isn't a so-called "microkernel." It doesn't use fancy queues of any sort, when dealing with "user space."

(And Linus has a great deal to say about that!)

When a system call occurs, the process transitions into "kernel mode," during which time it temporarily "dons its Superman® Suit" while executing code that is within the kernel space. It does not, during that time, shed its identity. The system's process-dispatcher still understands that "so-and-so process is in charge," although the process is no longer "arbitrarily pre-emptable." (At this point, it will not "lose" control of the CPU due to an incoming timer-interrupt: rather, it must "give up" control.)

Most system calls, after all, really are "over-glorified subroutine(!) calls." A process-context switch is not required ... merely "the donning, and then the subsequent doffing, of a Superman® Suit." The process dons the blue tights, flies to the planet Krypton (and back again), then resumes being Clark Kent, as though nothing-at-all had happened. And, since this is in fact what usually happens, "hey, let's not make it over-complicated, shall we?"

("Because if we do, we shall have to debug it!!")

The general design of the Linux operating system is that, for the most part, a process is in charge of its own affairs, whether it happens to be running in "user mode" or "kernel mode." Anything that is not "directly under the auspices of a particular user process" is either reserved to "an interrupt handler" (first-level or second-level), which so-to-speak "runs in-between" processes, or to a "kernel thread."

The concept of a "kernel thread" is that it is an invention that is specifically designed to handle those parts of the kernel which really do need to operate asynchronously ... such as the swapper. This design allows these kernel-activities to be handled, along with all other system activities, by a single body of "per-core time-dispatching" code: sched.c.

The design of this OS appears to be quite-consciously designed to be "at all times, predictable." And that is probably a very wise thing.

Last edited by sundialsvcs; 10-31-2016 at 06:51 PM.
 
Old 10-31-2016, 11:16 PM   #33
linux4evr5581
Member
 
Registered: Sep 2016
Location: USA
Posts: 275

Original Poster
Rep: Reputation: Disabled
Thanks for you response, I appreciate the explanation, im just trying to apply knowledge that I have learned to see how accurate my educated guesses are..
 
Old 11-01-2016, 01:07 AM   #34
Jjanel
Member
 
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
Blog Entries: 12

Rep: Reputation: 361Reputation: 361Reputation: 361Reputation: 361
A big thanks to jlliagre for jumping in last night, and the others today!

I didn't even know about the 'new 1997' sysenter (vs. INT) cpu instruction! Wow!
(...remembering my 1st Unix, 1980s, adding 'arp' to 4.1BSD/SunOS1.x kernel at ValidLogicSystems)

http://0xax.gitbooks.io/linux-inside...syscall-2.html
looks interesting (even mentions OP's prior k-devel thread. Soooo much to find&read...

An idea: mikeos or even less! Note to self: jump in & DO stuff
 
Old 11-01-2016, 04:36 AM   #35
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,844

Rep: Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477Reputation: 1477
Quote:
Originally Posted by sundialsvcs View Post
Huh?!

It frankly seems to me that lots of people are seriously over-thinking this thing!

The Linux system (versus other operating systems ...) tries rather hard not to be "too clever." It isn't a so-called "microkernel." It doesn't use fancy queues of any sort, when dealing with "user space."
Evidently you haven't met the dcache... or the disk scheduler either. Or the kernel task queues.
Quote:

(And Linus has a great deal to say about that!)
Have a look at the terminal driver for instance. Lots of queuing being done.
Quote:

When a system call occurs, the process transitions into "kernel mode," during which time it temporarily "dons its Superman® Suit" while executing code that is within the kernel space. It does not, during that time, shed its identity. The system's process-dispatcher still understands that "so-and-so process is in charge," although the process is no longer "arbitrarily pre-emptable." (At this point, it will not "lose" control of the CPU due to an incoming timer-interrupt: rather, it must "give up" control.)

Most system calls, after all, really are "over-glorified subroutine(!) calls." A process-context switch is not required ... merely "the donning, and then the subsequent doffing, of a Superman® Suit." The process dons the blue tights, flies to the planet Krypton (and back again), then resumes being Clark Kent, as though nothing-at-all had happened. And, since this is in fact what usually happens, "hey, let's not make it over-complicated, shall we?"
Yes, most system calls are just giving or receiving information.

But some are more complex than that. Opening a file... scheduling disk blocks to be read, but not given to the user. Metadata manipulation, network packet handling,
Quote:

("Because if we do, we shall have to debug it!!")

The general design of the Linux operating system is that, for the most part, a process is in charge of its own affairs, whether it happens to be running in "user mode" or "kernel mode." Anything that is not "directly under the auspices of a particular user process" is either reserved to "an interrupt handler" (first-level or second-level), which so-to-speak "runs in-between" processes, or to a "kernel thread."
and only does so due to system calls initiating the activity.
Quote:

The concept of a "kernel thread" is that it is an invention that is specifically designed to handle those parts of the kernel which really do need to operate asynchronously ... such as the swapper. This design allows these kernel-activities to be handled, along with all other system activities, by a single body of "per-core time-dispatching" code: sched.c.

The design of this OS appears to be quite-consciously designed to be "at all times, predictable." And that is probably a very wise thing.
Never said otherwise.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
how does java calls the system calls which are written in c babu198649 Linux - General 3 12-05-2011 04:40 AM
System Calls AlbertJJ Programming 7 10-27-2010 10:45 AM
system calls with C khodeir Programming 4 03-12-2009 09:26 PM
system calls goldeneagle1234 Linux - Newbie 1 09-14-2008 05:52 AM
Some system calls Spooky Programming 1 11-24-2004 11:17 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 04:53 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration