Unix system calls (1/2)

[Rnegade]

9 years later and this is the best resource on the topic. Really great.

[DragisaBoca]

Very well made, you made the world a better place.

[sodapopinski]

so many levels of abstraction, by the time people are clicking on their GUI's it is a symphony of perfect timed and executed processes, but listening to this I can really imagine year after year problems develop and more complicated solutions come into play stepping up a level of abstraction, I mean 60 years is so impressive to see how for we come, from logic gates, MOSFETS to EEPROMS to insane clock speeds to RISC to now but it all started at a level of someone feeding an electronic impulse into a JK FLIP FLOP and trapping that high or low impulse.... it is truly baffling!!!!

[BlackMsh]

At 31:50 you talk about environment variables. However there are some mistakes worth correcting for future viewers. First, although the environment variables are stored in the process' memory, it is stored as zero-terminated strings and not as one big string separated by new-line characters. It is also is not stored on the heap, nor is there a global variable in the data section pointing to it. The environment is actually stored entirely on the stack and is a part of the initial process stack that is set up before the program starts running. The first value on the stack is the argument count followed by an array of the addresses of the different arguments, then address 0 marking the end of the argument array. Right after that there is a second array of addresses which each point to a zero-terminated string which would be the environment variables, this array is also terminated by having address 0 at the end. There is actually a third array of auxiliary vectors but after that there is an unspecified amount of bytes before the information block starts. It's generally inside this block the command line arguments and environment variables are stored, as in the actual string values. You can confirm this by dumping the stack of pretty much any program and you typically find all the environment variables at the very end (highest memory address). If you are on Linux you can do this by first reading the '/proc/<pid>/maps' file for any process, just replace <pid> with that process' PID. This file contains the ranges of memory mapped to the process and what they are mapped to. Near the bottom you'll see one line with the range mapped to [stack]. Take note of the start address and calculate how big it is in bytes. Then run 'sudo xxd -s <start-address> -l <size-in-bytes> /dev/<pid>/mem', example 'sudo xxd -s 0x7fff182bd000 -l 0x22000 /dev/14950/mem'. And the environment variables should get printed out together with their hex values and address location.

To illustrate this further I've written a small c program that prints all the environment variables using the argv array pointer. As you can see the environment variable pointers are stored pretty much right after argv.

#include <stdio.h>
int main(int argc, char **argv)
{
for (int i = argc + 2; argv[i] != NULL; i++)
{
printf("%s\n", argv[i]);
}
return 0;
}


You can of course make it less stupid by using the full version of main which includes a pointer to the first element in the environment pointer array.

#include <stdio.h>
int main(int argc, char **argv, char **envp)
{
for (int i = 0; envp[i] != NULL; i++)
{
printf("%s\n", envp[i]);
}
return 0;
}

This is all defined as a part of the ABI (application binary interface) for both the x86 and x86_64 architecture, so 32 and 64 bit desktop computers.

tl;dr: The environment is not a single long string separated by new-line characters. The environment variables and the pointers to them are both stored on the stack or just before it.

[eshgholah]

I have loved every second of your videos. Specially the Unix system call series. Could you please kindly do an advanced series of Linux Internals. I know it is too much to ask but obviously you are the right person to do it. I have never seen anyone else describing things so clear and nicely. Thanks a million.

[nikkehtine]

High quality presentation and commentary. We get such a long, interesting and informative video for the great low price of free. Thank you so much.

[fouzaialaa]

i studied this in my engineering class and it took them almost 4 months to teach us this ...this 45 minute lecture made it so easy and simple !!! in uni they stretched it so much that you forget about it start questioning everything again every lecture
thx for the upload

[Synchrnix]

I've been watching this video series every day, for the last 3 days, and I learn a little more from it each time, lol. Thanks man. This is one of the most professional lessons I've ever found on YouTube. I can tell you know what you're talking about.

[AdamOutler]

This is a very informative Linux/Unix System Calls series.

[REOsama]

My head is spinning, this is the most meaty video I've ever watched, you are an unsung hero

[pouryamehdinejad]

The best explanation of system calls I could find on the internet.
Thanks to Brian Will

[kshahkshah]

This is a truly excellent, informative and well laid out video. Thank you so much. I've been coding for 15+ years and got a lot out of this, especially having mostly dealt in interpreted dynamic languages and not having to ever manage memory myself

[rzathamesmer]

More Unix videos please! You're an excellent teacher, and the slides are very well done.

[leonbishop]

2:00 kinda sus abbreviation you got there

[crptc]

It's a fantastic tutorial! I've been baffled with kernel space and user space for quite a long time and misunderstood that system call incurs context switch between user process and kernel process, until I watched this video... million thanks!

[mbigras]

I’ve searched for a video like yours for a long time, thank you so much for this work!

[ben]

I just discovered your channel and can't stop watching your videos! They're incredibly helpful and clear.

Just wanted to say it seems to me this and the next video should be added to your Operating Systems playlist.

[briantwill]

I'm no expert issue on this issue, but my investigation at the time concluded that brk/sbrk are actually archaic, as the concept of a data segment barrier is outmoded in paged-memory environments. Yes, mapping /dev/mem is not the way to go, but mmap in modern Unixes can do 'annonymous mapping, ' which maps to swap-backed memory pages rather than any file. The Wikipedia entry on mmap mentions this. I believe this is what most allocation routines use today, not brk/sbrk.

[tigeruppercut]

One of the most solid videos I've seen on Linux. Great job. Thanks.

[greymind]

Thanks for making this gem of a video. Your content is lucid and enriching at the same time