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

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.

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..

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

Evidently you haven't met the dcache... or the disk scheduler either. Or the kernel task queues.
Have a look at the terminal driver for instance. Lots of queuing being done.
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,
and only does so due to system calls initiating the activity.
Never said otherwise.