Soma-notes - User contributions [en]

Operating Systems (Fall 2026)

2026-10-09T23:46:22Z

Soma: /* Lectures & Exams */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
'''No class ([https://www.nspw.org NSPW])''' (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] '''No class on Oct 1 ([https://www.nspw.org NSPW])'''

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 10|Midterm Review]]

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
'''Midterm Exam (in class)'''

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Dec. 17, 9 AM

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 15, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems 2026F Lecture 8

2026-10-09T15:00:19Z

Soma: /* Video */

==Readings==

The following readings are supplemental but may help you understand what has been covered in previous classes:

UNIX permissions
* ''Operating System Concepts'', Section 13.4.2, Access control (p. 552-554)

setuid
* ''Operating System Concepts'', Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories
* ''Operating Systems: Three Easy Pieces'', [https://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Chapter 39: Interlude: Files and Directories]

==Topics==

* Introduction to networking
* UNIX accounts
* password security
* Public key cryptography
* ssh configuration and usage

==Video==

Video from the lectures given on October 8th and 9th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec08a-20261008.mp4 Lecture 8A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec08b-20261009.mp4 Lecture 8B]

Unfortunately the screen capture got messed up with these, my apologies.

==Notes==

===Lecture 8A===

<pre>
Lecture 8A
----------

Wooclap: ALMBSXY

Why tutorials then assignments?
- we can grade only so much
- but I also want to encourage you to judge whether you understand something or not

How does the Internet work?
- postcards going this way and that

Why postcards?
- because they show who they are from and who they are for
- limited in size
- "public"

What if you wanted to communicate a lot of information via postcards?
- break up the message into postcard-sized chunks
- number the postcards

But then what if they arrive out of order, get delayed, or get lost?
- need some way of checking what information is missing

IP <- postcards (packets)
TCP <- strategy for getting continuous communication over IP packets,
making sure it is reliable
UDP <- let me manage the postcards myself

So how can we protect these postcards?
- cryptography!

Classic cryptography relies on shared secrets
- both sides know the "password"

But a shared secret only works if both parties have been previously introduced
- not the case on the Internet!

In the 1970's, cryptographers figured out something much more clever:
public key cryptography

public key cryptography splits the "secret" into two:
- a public key that is shared with everyone
- a private key that is...private

With public key cryptography, you can
- send a secret message to anyone you have the public key for
- verify the authenticity & integrity of a message for anyone you have the public key (check the digital signature)

Now the sharing a secret key problem - we can just send a key as a public key-encrypted message
- but how do I know I have the right public key?

To enable passwordless login to an openstack VM
- generate an SSH key pair
- copy the public key (the .pub file) to the .ssh/authorized_keys file
on the openstack VM
- add the key pair to your local ssh agent
- this varies depending on your operating system, but is
generally "ssh-add" and the private key file

The purpose of ssh-add is to add your unlocked private key to your local ssh agent
- the idea is that you don't want to keep having to unlock your private key, but you want your private key to be protected on disk

PASSWORDS
- so passwords are stored locally, but does that mean if someone logs into your computer they automatically know your password?
- passwords are stored with secure hashes
- the hash of the password is remembered, not the password
- if you have the hash you only know the password if you guess it correctly
</pre>

===Lecture 8B===

<pre>
Lecture 8B
----------
wooclap: EUJSUZN

There are textbook resources
- read them for contextual information

but you need to approach the material intentionally
- I can't build a conceptual model for you

Before explaining SSH, we need to explain why we need it
So...networking

Why postcards?
- have a sender and a receiver (source and destination)
- limited size
- "public" - anyone who handles the postcard can read it

packets are basically postcards
- and that's what is sent around on the Internet

If you want to send a lot of information, that means a lot of postcards
- what order?
- what if one gets lost? Delayed?
- privacy?
- integrity (no changes)
- authenticity (correct sender)?

The Internet was built originally with NO SECURITY
- no privacy, integrity, authenticity

Instead it was "best effort"
- mistakes will be made

Internet routers - think the post office

So how do we solve the security problem? By using cryptography!
- classic cryptography is all about ciphers for encryption

symmetric key cryptography:
plaintext + secret key => ciphertext
ciphertex + secret key => plaintext

Old: substitution ciphers, enigma
Recent: DES
Current: AES

The challenge of symmetric key cryptography is a chicken & egg problem:
- how do you share a key?

Solution: public key cryptography

public key cryptography:
plaintext + public key => ciphertext
ciphertex + private key => plaintext

public and private key are a matched pair that are generated together

But how do I make sure things haven't been changed in transit?
- integrity, authenticity?

secure hash functions
- generating hashes from a document are easy
- finding a document with a given hash is hard

So if I have the hash of a document and the hash is correct, I know I got the right document

But then, how do I know I got the right hash?

public key cryptography (digital signature):
hash + private key => signature
signature + public key => hash

To check a signature of a document:
compute hash(document)
hash(document) ?= hash from signature

If they match, then document is authentic (came from owner of key) and hasn't been changed

(don't implement your own cryptography!)

So how do I know I have the right public key for someone?
- well, we can just use digital signatures again!

certificate: public key + metadata (name, expiration, etc)

setuid bit
- goes with the execute bit
- when execve is run, makes the euid of the process the uid of the executable

euid: effective uid, the real uid the kernel uses to decide access

normally uid=euid for a process, but setuid lets this change
</pre>

Operating Systems 2026F Lecture 8

2026-10-09T14:50:32Z

Soma: /* Video */

==Readings==

The following readings are supplemental but may help you understand what has been covered in previous classes:

UNIX permissions
* ''Operating System Concepts'', Section 13.4.2, Access control (p. 552-554)

setuid
* ''Operating System Concepts'', Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories
* ''Operating Systems: Three Easy Pieces'', [https://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Chapter 39: Interlude: Files and Directories]

==Topics==

* Introduction to networking
* UNIX accounts
* password security
* Public key cryptography
* ssh configuration and usage

==Video==

Video from the lectures given on October 8th and 9th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec08a-20261008.mp4 Lecture 8A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec08b-20261009.mp4 Lecture 8B]

==Notes==

===Lecture 8A===

<pre>
Lecture 8A
----------

Wooclap: ALMBSXY

Why tutorials then assignments?
- we can grade only so much
- but I also want to encourage you to judge whether you understand something or not

How does the Internet work?
- postcards going this way and that

Why postcards?
- because they show who they are from and who they are for
- limited in size
- "public"

What if you wanted to communicate a lot of information via postcards?
- break up the message into postcard-sized chunks
- number the postcards

But then what if they arrive out of order, get delayed, or get lost?
- need some way of checking what information is missing

IP <- postcards (packets)
TCP <- strategy for getting continuous communication over IP packets,
making sure it is reliable
UDP <- let me manage the postcards myself

So how can we protect these postcards?
- cryptography!

Classic cryptography relies on shared secrets
- both sides know the "password"

But a shared secret only works if both parties have been previously introduced
- not the case on the Internet!

In the 1970's, cryptographers figured out something much more clever:
public key cryptography

public key cryptography splits the "secret" into two:
- a public key that is shared with everyone
- a private key that is...private

With public key cryptography, you can
- send a secret message to anyone you have the public key for
- verify the authenticity & integrity of a message for anyone you have the public key (check the digital signature)

Now the sharing a secret key problem - we can just send a key as a public key-encrypted message
- but how do I know I have the right public key?

To enable passwordless login to an openstack VM
- generate an SSH key pair
- copy the public key (the .pub file) to the .ssh/authorized_keys file
on the openstack VM
- add the key pair to your local ssh agent
- this varies depending on your operating system, but is
generally "ssh-add" and the private key file

The purpose of ssh-add is to add your unlocked private key to your local ssh agent
- the idea is that you don't want to keep having to unlock your private key, but you want your private key to be protected on disk

PASSWORDS
- so passwords are stored locally, but does that mean if someone logs into your computer they automatically know your password?
- passwords are stored with secure hashes
- the hash of the password is remembered, not the password
- if you have the hash you only know the password if you guess it correctly
</pre>

===Lecture 8B===

<pre>
Lecture 8B
----------
wooclap: EUJSUZN

There are textbook resources
- read them for contextual information

but you need to approach the material intentionally
- I can't build a conceptual model for you

Before explaining SSH, we need to explain why we need it
So...networking

Why postcards?
- have a sender and a receiver (source and destination)
- limited size
- "public" - anyone who handles the postcard can read it

packets are basically postcards
- and that's what is sent around on the Internet

If you want to send a lot of information, that means a lot of postcards
- what order?
- what if one gets lost? Delayed?
- privacy?
- integrity (no changes)
- authenticity (correct sender)?

The Internet was built originally with NO SECURITY
- no privacy, integrity, authenticity

Instead it was "best effort"
- mistakes will be made

Internet routers - think the post office

So how do we solve the security problem? By using cryptography!
- classic cryptography is all about ciphers for encryption

symmetric key cryptography:
plaintext + secret key => ciphertext
ciphertex + secret key => plaintext

Old: substitution ciphers, enigma
Recent: DES
Current: AES

The challenge of symmetric key cryptography is a chicken & egg problem:
- how do you share a key?

Solution: public key cryptography

public key cryptography:
plaintext + public key => ciphertext
ciphertex + private key => plaintext

public and private key are a matched pair that are generated together

But how do I make sure things haven't been changed in transit?
- integrity, authenticity?

secure hash functions
- generating hashes from a document are easy
- finding a document with a given hash is hard

So if I have the hash of a document and the hash is correct, I know I got the right document

But then, how do I know I got the right hash?

public key cryptography (digital signature):
hash + private key => signature
signature + public key => hash

To check a signature of a document:
compute hash(document)
hash(document) ?= hash from signature

If they match, then document is authentic (came from owner of key) and hasn't been changed

(don't implement your own cryptography!)

So how do I know I have the right public key for someone?
- well, we can just use digital signatures again!

certificate: public key + metadata (name, expiration, etc)

setuid bit
- goes with the execute bit
- when execve is run, makes the euid of the process the uid of the executable

euid: effective uid, the real uid the kernel uses to decide access

normally uid=euid for a process, but setuid lets this change
</pre>

Operating Systems 2026F Lecture 8

2026-10-09T14:50:19Z

Soma:

==Readings==

The following readings are supplemental but may help you understand what has been covered in previous classes:

UNIX permissions
* ''Operating System Concepts'', Section 13.4.2, Access control (p. 552-554)

setuid
* ''Operating System Concepts'', Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories
* ''Operating Systems: Three Easy Pieces'', [https://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Chapter 39: Interlude: Files and Directories]

==Topics==

* Introduction to networking
* UNIX accounts
* password security
* Public key cryptography
* ssh configuration and usage

==Video==

Video from the lectures given on October 8th and 9th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec08a-20261008.mp4 Lecture 7A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec08b-20261009.mp4 Lecture 7B]

==Notes==

===Lecture 8A===

<pre>
Lecture 8A
----------

Wooclap: ALMBSXY

Why tutorials then assignments?
- we can grade only so much
- but I also want to encourage you to judge whether you understand something or not

How does the Internet work?
- postcards going this way and that

Why postcards?
- because they show who they are from and who they are for
- limited in size
- "public"

What if you wanted to communicate a lot of information via postcards?
- break up the message into postcard-sized chunks
- number the postcards

But then what if they arrive out of order, get delayed, or get lost?
- need some way of checking what information is missing

IP <- postcards (packets)
TCP <- strategy for getting continuous communication over IP packets,
making sure it is reliable
UDP <- let me manage the postcards myself

So how can we protect these postcards?
- cryptography!

Classic cryptography relies on shared secrets
- both sides know the "password"

But a shared secret only works if both parties have been previously introduced
- not the case on the Internet!

In the 1970's, cryptographers figured out something much more clever:
public key cryptography

public key cryptography splits the "secret" into two:
- a public key that is shared with everyone
- a private key that is...private

With public key cryptography, you can
- send a secret message to anyone you have the public key for
- verify the authenticity & integrity of a message for anyone you have the public key (check the digital signature)

Now the sharing a secret key problem - we can just send a key as a public key-encrypted message
- but how do I know I have the right public key?

To enable passwordless login to an openstack VM
- generate an SSH key pair
- copy the public key (the .pub file) to the .ssh/authorized_keys file
on the openstack VM
- add the key pair to your local ssh agent
- this varies depending on your operating system, but is
generally "ssh-add" and the private key file

The purpose of ssh-add is to add your unlocked private key to your local ssh agent
- the idea is that you don't want to keep having to unlock your private key, but you want your private key to be protected on disk

PASSWORDS
- so passwords are stored locally, but does that mean if someone logs into your computer they automatically know your password?
- passwords are stored with secure hashes
- the hash of the password is remembered, not the password
- if you have the hash you only know the password if you guess it correctly
</pre>

===Lecture 8B===

<pre>
Lecture 8B
----------
wooclap: EUJSUZN

There are textbook resources
- read them for contextual information

but you need to approach the material intentionally
- I can't build a conceptual model for you

Before explaining SSH, we need to explain why we need it
So...networking

Why postcards?
- have a sender and a receiver (source and destination)
- limited size
- "public" - anyone who handles the postcard can read it

packets are basically postcards
- and that's what is sent around on the Internet

If you want to send a lot of information, that means a lot of postcards
- what order?
- what if one gets lost? Delayed?
- privacy?
- integrity (no changes)
- authenticity (correct sender)?

The Internet was built originally with NO SECURITY
- no privacy, integrity, authenticity

Instead it was "best effort"
- mistakes will be made

Internet routers - think the post office

So how do we solve the security problem? By using cryptography!
- classic cryptography is all about ciphers for encryption

symmetric key cryptography:
plaintext + secret key => ciphertext
ciphertex + secret key => plaintext

Old: substitution ciphers, enigma
Recent: DES
Current: AES

The challenge of symmetric key cryptography is a chicken & egg problem:
- how do you share a key?

Solution: public key cryptography

public key cryptography:
plaintext + public key => ciphertext
ciphertex + private key => plaintext

public and private key are a matched pair that are generated together

But how do I make sure things haven't been changed in transit?
- integrity, authenticity?

secure hash functions
- generating hashes from a document are easy
- finding a document with a given hash is hard

So if I have the hash of a document and the hash is correct, I know I got the right document

But then, how do I know I got the right hash?

public key cryptography (digital signature):
hash + private key => signature
signature + public key => hash

To check a signature of a document:
compute hash(document)
hash(document) ?= hash from signature

If they match, then document is authentic (came from owner of key) and hasn't been changed

(don't implement your own cryptography!)

So how do I know I have the right public key for someone?
- well, we can just use digital signatures again!

certificate: public key + metadata (name, expiration, etc)

setuid bit
- goes with the execute bit
- when execve is run, makes the euid of the process the uid of the executable

euid: effective uid, the real uid the kernel uses to decide access

normally uid=euid for a process, but setuid lets this change
</pre>

Operating Systems 2026F Lecture 8

2026-10-08T17:49:07Z

Soma:

Operating Systems 2026F Lecture 8

2026-10-08T17:48:49Z

Soma: /* Topics */

==Readings==

The following readings are supplemental but may help you understand what has been covered in class:

UNIX permissions
* ''Operating System Concepts'', Section 13.4.2, Access control (p. 552-554)

setuid
* ''Operating System Concepts'', Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories
* ''Operating Systems: Three Easy Pieces'', [https://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Chapter 39: Interlude: Files and Directories]

==Topics==

* Introduction to networking
* UNIX accounts
* password security
* Public key cryptography
* ssh configuration and usage

Operating Systems 2026F Lecture 8

2026-10-08T17:46:14Z

Soma:

==Readings==

The following readings are supplemental but may help you understand what has been covered in class:

UNIX permissions
* ''Operating System Concepts'', Section 13.4.2, Access control (p. 552-554)

setuid
* ''Operating System Concepts'', Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories
* ''Operating Systems: Three Easy Pieces'', [https://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Chapter 39: Interlude: Files and Directories]

==Topics==

* Introduction to networking
* Public key cryptography
* password security
* ssh configuration and usage

Operating Systems 2026F Lecture 8

2026-10-08T17:18:01Z

Soma: Created page with "==Readings== The following readings are supplemental but may help you understand what has been covered in class: UNIX permissions * ''Operating System Concepts'', Section 13.4.2, Access control (p. 552-554) setuid * ''Operating System Concepts'', Section 17.4.2, Example: UNIX (p. 674-675) Files and directories * ''Operating Systems: Three Easy Pieces'', [https://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Chapter 39: Interlude: Files and Directories]"

Operating Systems 2026F Lecture 7

2026-10-07T17:57:17Z

Soma: Created page with "==Video== Video from the lectures given on October 6th and 7th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07a-20261006.mp4 Lecture 7A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07b-20261007.mp4 Lecture 7B] ==Notes== ===Lecture 7A=== <pre> Lecture 7A ---------- Tutorial 4! Apps ------ Kernel <--- has more privileges ------- Hardware Implemented on the CPU through..."

==Video==

Video from the lectures given on October 6th and 7th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07a-20261006.mp4 Lecture 7A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec07b-20261007.mp4 Lecture 7B]

==Notes==

===Lecture 7A===

<pre>
Lecture 7A
----------

Tutorial 4!

Apps
------
Kernel <--- has more privileges
-------
Hardware

Implemented on the CPU through different modes.

UNIX-like systems expect there to be a supervisor mode and a user mode.
- supervisor mode: can access everything
- user mode: limited access

processes run in user mode
the kernel runs in supervisor mode

a "process" is an abstraction over sharing of user mode

the kernel doesn't share supervisor mode - that's all that runs

Linux
- name of an implementation of a operating system kernel
- designed to be basically compatible with POSIX

POSIX
- set of standards defining what a UNIX-like system is

UNIX
- operating system created by engineers at Bell Labs (AT&T) in the early 1970's

AT&T had been ruled a monopoly so they had lots of rules about what they could and could not do
- they weren't allowed to compete in the commputer market
- but their engineers made a nice OS
- so, they basically gave away UNIX
- very permissive licenses
- adopted by a lot of universities, esp ones who were developing the Internet

UNIX is a pun on MULTICS

BSD UNIX - Berkeley variant of UNIX that was where a lot of Internet technologies were prototyped

But then BSD UNIX got big, and so commercial UNIX became a thing in the 1980's
- on scientific workstations and other bigger machines

But every company that made a UNIX workstation made their own proprietary version of UNIX
- permissive license from AT&T plus Berkeley giving away their code

These variations got to be such a pain that there came an effort to standardize what a "UNIX-like" system should be
- this resulted in POSIX

UNIX is trademarked
- not everyone can call their OS UNIX

In the early 1990's two things happened
- The web arrived (1992-1993)
- CPUs capable of UNIX became available in PCs
- 80386 starting in 1985
- 80486 starting in 1989

So a commercial UNIX could have taken over
- Microsoft actually sold XENIX for PCs

But really a version of BSD UNIX should have been available for PCs around then and should have been the foundation of the modern Internet
- was open source and battle tested

What happened?

AT&T got greedy
- was free of antitrust concerns
- and UNIX had become valuable
- so they went and sued the people who were making BSD UNIX

Linux is the product of three things
- AT&T's lawsuits
- the GNU project not making a kernel
- a finnish CS undergrad hacking around

The GNU project
- project of the Free Software Foundation
- stands for GNU's not UNIX
- FSF people (led by Richard Stallman) got tired of proprietary UNIX
- wanted THE CODE so they could make their own changes and share
them
- so they decided to make their own version of a UNIX-like system

- gcc instead of cc
- bash instead of sh
- bison instead of lex

All under the GPL

GPL - GNU General Public License
- if you distribute, you have to share the source code with binaries
- source code should be distributable under same terms

The GNU project did this for essentially all of userspace of a UNIX system by the early 1990's. But it couldn't run on bare hardware because they didn't have a kernel.
- GNU Herd was stalled

And then Linus Torvalds came along
- got people on the Internet collaborating on making a kernel

People say GNU/Linux because it is the Linux kernel with a GNU userland
- but nowadays that isn't always true (e.g., busybox)

Linux distribution: Linux kernel + some userspace code

So with UNIX, you have code running in supervisor mode (kernelspace) and in user mode (userspace)

We're now focused on userspace, will talk about kernelspace more after the midterm

So when a process wants to do something with files, it must make system calls
- system call is a request to the kernel
- kernel can say yes or no

On what basis does the kernel say yes or no?

Wooclap code: AFAGNUX

First, it depends on which process and which file

Some processes can access everything
Some have limited access

What mainly determines access is the user who owns the process
- i.e., the uid associated with the owner field of the process

Files on UNIX have an associated uid and gid (user and group)
And permissions associated with these.

three groups of read, write, execute bits
- yes or no for each
plus a few other bits

The rwx are for:
- the user
- the group
- other (everyone else)

To read a file, you need read access
- first check to see if uid of process equals uid of file
- and user read bit enabled
- then check gid of process equals gid of file
- and group read bit enabled
- then check if other read bit enabled

But what about directories?
- marked by a "d" bit

When you run ls, you're reading the contents of the current directory
- represented by "."
- ".." is the parent directory

To be able to list

What's really happening is that the contents of a file is represented as an inode
- inodes are numbered per filesystem

A directory is just a mapping of names to inodes

With r permission, you can read the mappings of names to inodes in a directory

With x permission, you can get the inode associated with a name

file permissions are actually inode permission in UNIX

hard links are just name to inode associations
(what directories mostly contain)

symbolic links are name to name associations

So what's special about root (uid=0)?
- the kernel treats those processes as being allowed to do almost anything

When you use sudo, you are saying "superuser (root) do this"
- better than logging in as root, because it is clear what is being done with elevated privileges

If you just want to be root, run "su" - but you need the root password.

Alternately, run "sudo -i" to login as root if your user has sudo privileges.

setuid bit
- goes with the executable bit on a file, but separate

when a process execve's a program with the setuid bit, the *euid* of the process changes to that of the program file
</pre>

===Lecture 7B===

<pre>
Lecture 7B
----------

Wooclap 1: OEHHFJX
Be sure to be logged in!

Today is Tutorial 4, plus some history

Applications (processes)
-------
Kernel
--------
Hardware

kernel and applications take turns on the CPU
- key difference is their privilege levels

So the kernel runs in "supervisor mode", while
processes run in "user mode" on the CPU
- full access in supervisor mode
- limited access in user mode

the process abstraction is a way to multiplex user mode

System calls are how code in user mode invokes code in supervisor mode, i.e., how processes call the kernel
- special mechanism because function calls don't work

So what are permissions for?
- tells the kernel what privileges different processes should have, i.e., what resources it should be given access to

We mainly see permissions associated with two things:
- processes
- files

So when a process accesses a file, the kernel decides whether it is allowed or not based on the permission model

Permissions are generally in some sort of access control matrix
- rows are entities
- columns are specific permissions
UNIX uses a simplified access control model for efficiency and usability

I've been saying UNIX, Linux, UNIX-like...why?

UNIX is a trademark of AT&T
- because it came out of Bell Labs in the early 1970's
- wasn't really a product at first because was
just made by a few engineers for their own use
- and AT&T wasn't allowed to commercialize it really
- they were under antitrust restrictions
- so they almost gave it away
- very open license terms for whomever wanted it

When researchers wanted to create the Internet in the late 1970's, they mostly built upon UNIX
- researchers at Berkeley modified it to make BSD UNIX

So to get on the Internet people wanted to run BSD UNIX, and so it spread
- first as itself
- then in commercial form from workstation vendors in the 1980's (e.g., Sun Microsystems)

Because of the licensing terms, workstation manufacturers all could make proprietary versions of UNIX
- based on generally available code but with lots of proprietary modifications/additions

Got so bad there was an effort to standardize what "UNIX" should be
- resulted in the POSIX standards

So UNIX should have been the basis of the web starting in the early 1990's, but a few things happened
- PCs got powerful enough to run UNIX
- Intel 80386 in 1985, 80486 in 1989
- there were commercial versions of UNIX for PCs
- Microsoft made XENIX

Rather than proprietary UNIX, why couldn't PCs run a variant of BSD UNIX?
- it was still around, had its own variants
- but AT&T decided to sue the creators of BSD UNIX

Another piece was the GNU Project
- from the Free Software Foundation
- HATED proprietary UNIX, so decided to make their own

Started with the foundations
- gcc instead of cc
- bash rather than sh
- bison rather than lex

By the early 1990's, GNU had implementations of everything in core UNIX...except for the kernel
- there was the GNU Herd, but it was VERY delayed

This is where a Finnish CS undergrad steps in
- Linus Torvalds posted his own hacked together kernel
- with the help of others, he
combined it with GNU userland, and now had a
UNIX-like system that came to be known as Linux

Strictly speaking, Linux is just the kernel
- to get a full UNIX-like system, need to add userspace
- Linux + userspace => Linux distribution
- people call Linux GNU/Linux because GNU project code
is often part of a Linux distribution
- but not always! (e.g., busybox)

One factor in the success of Linux is its license
- GNU GPL (General Public License)

"copyleft" license
- based on copyright to subvert copyright
- says you can distribute code as you like, BUT
- you have to give source with binary code
- can't add restrictions

Android has effectively circumvented the GPL of Linux
- VERY irritating

Back to permissions

every process has a user and a group
every file has a user, a group, and permissions

The permissions are
- read
- write
- execute
And are there for
- user
- group
- other (everyone else)
plus a few more bits we will discuss

execute for regular files means they can be run as programs
- when you compile a program the compiler makes its
output executable

Other bits:
d: marks a file as a directory
- maps filenames to file contents (inodes)

What do permissions mean on a directory?
- read lets you list the names in a directory
- execute lets you resolve a name to its associated value (i.e., inode)

If a directory is executable but not readable, you can access the contents of files in that directory, but you can't get a list of files in the directory (try it out!)

But this whole permission model begs a question -
how do we get around it?
- how do we get the right permissions in the first place?

One user is very special in UNIX: root (uid=0)
- is allowed to do basically anything by the kernel

So when you first log in, that process is running as root so it can then "become" any user it wants to
- called dropping privileges

But then what about sudo?
- goes the wrong way, from a less privileged process
to one with root capabilities
- "superuser (root) do"

s in ls means that the executable and the setuid bit are both set
- if just setuid and not executable, you get S
(almost never what you want)

With the setuid bit set, the effective uid of a process becomes that of the executable file

The kernel uses the effective uid to decide what is and isn't allowed
- normally uid=euid
- but setuid messes with it
</pre>

Operating Systems 2026F: Tutorial 4

2026-10-05T19:05:06Z

Soma:

In this tutorial you will learn about permissions, accounts, how logging in works, and ssh.

==Background==

In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have been allocated to the current process.

A process is an abstraction over the limited access of the CPU's user mode. All processes run in user mode. While kernel code can be doing work on behalf of a specific process, properly speaking no kernel code is in a process. Instead, the kernel implements the process abstraction.

The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

Most users have limited access. One user, <tt>root</tt> (with user ID of 0), has as much access as is possible from a process. The kernel will even allow the root process to modify how the kernel operates. Processes running as root are still just processes, though, and any access that the kernel gives to such processes is at the discretion of the kernel. (In fact, there are setups which limit the privileges of the root user.)

===File Permissions===

A process' permission to access files in UNIX is determined by the user and group associated with that process. When a person logs in, their initial process is given the user and group associated with their account. All child processes of that initial login process inherit the same user and group.

A user can belong to multiple groups but a process only belongs to one group at a time. (There are ways to change the group associated with a process.) A file is always owned by someone and is always associated with a group. All files on the UNIX file system (including directories and other special files) have three different sets of permissions:
* owner permissions
* group permissions
* other permissions
Each of these have read, write, and/or execute permissions along with some other special permissions.

One special permission is the ''setuid'' bit. When an executable has this bit set, the process will run as the user who owns that executable (rather than as the user associated with the process that did the execve). The setuid bit is particularly important when a file is owned by root, as it gives us a way for regular users to escape the bounds of normal permissions. We will see the setuid root bit in action in this tutorial.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Logging in to a UNIX system===

In order to log in to a UNIX system (Linux or otherwise), the following steps must occur (potentially not in this order).

# The user must authenticate themselves, proving their identity and that they are allowed to access the system. By default this is done through a username and password.
# A new process, U, should be created for the authenticated user.
# The login program must establish communication with the user via some communications channel. Normally this channel will be a device. Standard in, out, and error for U should be connected to this device.
# U changes uid and gid to that of the new user.
# U sets up other aspects of the user's context (mainly setting key environment variables).
# U does an execve of the user's chosen shell.

[[#Code|3000userlogin]] is a basic implementation of steps 4-6. (Steps 2 and 3 are accomplished by running 3000userlogin in a shell, as running an external command means the shell first creates a new process, as we have seen. We are skipping 1.)

===SSH===

Secure Shell, or ssh, is the standard method for accessing UNIX and UNIX-like systems remotely. It is a more secure replacement for older technologies such as [https://en.wikipedia.org/wiki/Berkeley_r-commands rsh] and [https://en.wikipedia.org/wiki/Telnet telnet].

The standard implementation of ssh is [http://www.openssh.org openssh], a version of ssh that was originally created for [https://www.openbsd.org/ OpenBSD] but has been ported to other systems. OpenBSD has a reputation for being the most secure UNIX-like system around. It tends to be a bit harder to configure, have less support for current hardware, and have lower overall performance than Linux-based systems; however, it can be very competitive for some workloads.

While ssh support password-based authentication, it is meant to be used with more secure forms of authentication. For example, ssh supports public key authentication, a type of authentication that makes use of [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]. Instead of a shared key (such as a password) that is known to both parties, with public key cryptography, keys come in two parts: a public part and a private part. The public part should be widely distributed, while the private part needs to be carefully secured.

Public key cryptography can be used to send secret messages to anyone you can get the public key for. With digital signatures, public key cryptography can also be used to verify the authenticity and integrity of messages, so long as we know the public key of the originating party.

With public key authentication, we use a key pair to authenticate rather than sending a password.

A cool feature of public key authentication is it is possible to automatically log into a system once the appropriate private key is made available, thus giving us the convenience of passwordless logins with better security than passwords.

==Setup==

===3000userlogin===

When 3000userlogin is properly compiled and set up, you can run

./3000userlogin someuser

and you'll be logged in as "someuser", assuming someuser exists.

You can add a user with the adduser command. For example, to create the user "someuser":

sudo adduser someuser

Note you'll have to answer several questions.

If you just compile 3000userlogin normally, you won't be able to log in as anyone except the current user. To compile and set up 3000userlogin, do the following:

gcc -O -Wall 3000userlogin.c -o 3000userlogin
sudo chown root:root 3000userlogin
sudo chmod u+s 3000userlogin

The chown command makes the binary owned by root, and the chmod command makes it setuid. Thus, when the program is execve'd it will have an effective user ID of root (euid=0).

Alternately, you can download the code and use the associated makefile to build by doing the following:

wget https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/tut4.tar.gz
tar xzf tut4.tar.gz
cd tut4
sudo apt install make # make isn't installed on the class VMs oops
make
make setuid

===SSH===

Install the openssh-server package (note on openstack it will already be installed, but on a default Ubuntu desktop install it won't be):

sudo apt-get install openssh-server

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Public key authentication===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

==Tasks==

# Compile and setup 3000userlogin as described above. Create a new user account. Verify that you can use 3000userlogin to login as the new user without typing the password of the new user.
# What is returned as the user's password by getpwnam()? Is this what you expected?
# Compare the uid, gid, euid, egid when running 3000userlogin as a regular user, running it setuid root, and running it as root (i.e., running it from a root shell without the setuid bit set). Also check to see what happens when you set the setgid bit (with different group IDs on the file).
# Why does 3000userlogin change its gid before changing its uid? What happens if you switch the order of these operations?
# Make 3000userlogin use the shell that is specified in the user's password entry. Check by making a new user and setting its shell to a new shell and then see if that new shell runs when you run 3000userlogin. You should change a user's shell with the chsh command, run as that user.
# Can you set 3000shell to be a user's default shell? What changes do you have to make for chsh to accept 3000shell? Does anything obvious break when running 3000shell this way, and how can you change 3000userlogin to fix it?
# Does a user's default shell have to be a regular shell? Could it instead be an arbitrary program? How do you know?
# How important is each of the environment variables that is set by 3000userlogin? Are these the only environment variables that are set after you successfully login?
# Note that 3000userlogin uses environ not envp (as an argument to main) to access environment variables. Why not use envp? (Try changing the code to use envp and see what happens.)
# Setup password-less login to your local system between the student and other account (or any two other accounts), following the above instructions. Note that the "local" account is the one you are running the ssh command on.
# Setup password-less login to access.scs.carleton.ca, following the instructions above.
# Secure shell can be used to directly run a command on another program rather than the default shell. For example, try "ssh student@localhost bc -l" and see that bc is run. When you do this, does ssh directly run the specified command or does it first run a shell and have the shell run the command? Use opensnoop.bt or execsnoop.bt to verify.
# What files in /etc does bash access when you login via 3000userlogin? How does this compare to what bash opens when you log in via ssh?
# '''(Optional):''' Prompt for the user's password before logging the user in. To do this, you'll need to get the right password hash and then figure out how to hash the entered password to check if it matches. See online guides about [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils how passwords are stored on Linux] for help.

==Code==

[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000userlogin.tar.gz Download code for this tutorial (3000userlogin.c and Makefile)]

===3000userlogin.c===

[https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/3000userlogin.c Download 3000userlogin.c]

<syntaxhighlight lang="c" line>
/* 3000userlogin.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
int result;
char *shell_argv[3];
char *username;
extern char **environ;
struct passwd *pw_entry;

if (argc < 2) {
fprintf(stderr, "Usage: %s <username>\n", argv[0]);
exit(-1);
}

printf("uid=%d, euid=%d, gid=%d, egid=%d\n",
getuid(), geteuid(), getgid(), getegid());

username = argv[1];

pw_entry = getpwnam(username);
if (pw_entry == NULL) {
fprintf(stderr, "Could not find user %s.\n", username);
exit(-2);
}

result = setgid(pw_entry->pw_gid);
if (result != 0) {
fprintf(stderr, "Failed to change to gid %d\n",
pw_entry->pw_gid);
exit(-3);
}

result = setuid(pw_entry->pw_uid);
if (result != 0) {
fprintf(stderr, "Failed to change to uid %d\n",
pw_entry->pw_uid);
exit(-4);
}

result = chdir(pw_entry->pw_dir);
if (result != 0) {
fprintf(stderr, "Failed to change to home dir %s\n",
pw_entry->pw_dir);
exit(-5);
}

shell_argv[0] = "bash";
shell_argv[1] = "--login";
shell_argv[2] = NULL;

clearenv();
setenv("USERNAME", pw_entry->pw_name, 1);
setenv("PATH", "/usr/bin:/bin", 1);
setenv("SHELL", "/bin/bash", 1);
setenv("HOME", pw_entry->pw_dir, 1);
setenv("COMP3000", "yes", 1);

execve("/bin/bash", shell_argv, environ);

fprintf(stderr, "Failed to exec bash\n");
return -6;
}
</syntaxhighlight>

===Makefile===

<syntaxhighlight lang="make" line>
.PHONY: setuid

3000userlogin: 3000userlogin.c
gcc -Wall -O 3000userlogin.c -o 3000userlogin

setuid: 3000userlogin
@echo "The following changes ownership to root, group to root, and sets the setuid bit on 3000userlogin:"
sudo chown root:root 3000userlogin && sudo chmod u+s 3000userlogin
@echo "3000userlogin is now setuid root!"
</syntaxhighlight>

Operating Systems 2026F: Tutorial 4

2026-10-04T19:47:06Z

Soma: /* Setup */

'''This tutorial is not yet finalized.'''

In this tutorial you will learn about permissions, accounts, how logging in works, and ssh.

==Background==

In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have been allocated to the current process.

A process is an abstraction over the limited access of the CPU's user mode. All processes run in user mode. While kernel code can be doing work on behalf of a specific process, properly speaking no kernel code is in a process. Instead, the kernel implements the process abstraction.

The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

Most users have limited access. One user, <tt>root</tt> (with user ID of 0), has as much access as is possible from a process. The kernel will even allow the root process to modify how the kernel operates. Processes running as root are still just processes, though, and any access that the kernel gives to such processes is at the discretion of the kernel. (In fact, there are setups which limit the privileges of the root user.)

===File Permissions===

A process' permission to access files in UNIX is determined by the user and group associated with that process. When a person logs in, their initial process is given the user and group associated with their account. All child processes of that initial login process inherit the same user and group.

A user can belong to multiple groups but a process only belongs to one group at a time. (There are ways to change the group associated with a process.) A file is always owned by someone and is always associated with a group. All files on the UNIX file system (including directories and other special files) have three different sets of permissions:
* owner permissions
* group permissions
* other permissions
Each of these have read, write, and/or execute permissions along with some other special permissions.

One special permission is the ''setuid'' bit. When an executable has this bit set, the process will run as the user who owns that executable (rather than as the user associated with the process that did the execve). The setuid bit is particularly important when a file is owned by root, as it gives us a way for regular users to escape the bounds of normal permissions. We will see the setuid root bit in action in this tutorial.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Logging in to a UNIX system===

In order to log in to a UNIX system (Linux or otherwise), the following steps must occur (potentially not in this order).

# The user must authenticate themselves, proving their identity and that they are allowed to access the system. By default this is done through a username and password.
# A new process, U, should be created for the authenticated user.
# The login program must establish communication with the user via some communications channel. Normally this channel will be a device. Standard in, out, and error for U should be connected to this device.
# U changes uid and gid to that of the new user.
# U sets up other aspects of the user's context (mainly setting key environment variables).
# U does an execve of the user's chosen shell.

[[#Code|3000userlogin]] is a basic implementation of steps 4-6. (Steps 2 and 3 are accomplished by running 3000userlogin in a shell, as running an external command means the shell first creates a new process, as we have seen. We are skipping 1.)

===SSH===

Secure Shell, or ssh, is the standard method for accessing UNIX and UNIX-like systems remotely. It is a more secure replacement for older technologies such as [https://en.wikipedia.org/wiki/Berkeley_r-commands rsh] and [https://en.wikipedia.org/wiki/Telnet telnet].

The standard implementation of ssh is [http://www.openssh.org openssh], a version of ssh that was originally created for [https://www.openbsd.org/ OpenBSD] but has been ported to other systems. OpenBSD has a reputation for being the most secure UNIX-like system around. It tends to be a bit harder to configure, have less support for current hardware, and have lower overall performance than Linux-based systems; however, it can be very competitive for some workloads.

While ssh support password-based authentication, it is meant to be used with more secure forms of authentication. For example, ssh supports public key authentication, a type of authentication that makes use of [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]. Instead of a shared key (such as a password) that is known to both parties, with public key cryptography, keys come in two parts: a public part and a private part. The public part should be widely distributed, while the private part needs to be carefully secured.

Public key cryptography can be used to send secret messages to anyone you can get the public key for. With digital signatures, public key cryptography can also be used to verify the authenticity and integrity of messages, so long as we know the public key of the originating party.

With public key authentication, we use a key pair to authenticate rather than sending a password.

A cool feature of public key authentication is it is possible to automatically log into a system once the appropriate private key is made available, thus giving us the convenience of passwordless logins with better security than passwords.

==Setup==

===3000userlogin===

When 3000userlogin is properly compiled and set up, you can run

./3000userlogin someuser

and you'll be logged in as "someuser", assuming someuser exists.

You can add a user with the adduser command. For example, to create the user "someuser":

sudo adduser someuser

Note you'll have to answer several questions.

If you just compile 3000userlogin normally, you won't be able to log in as anyone except the current user. To compile and set up 3000userlogin, do the following:

gcc -O -Wall 3000userlogin.c -o 3000userlogin
sudo chown root:root 3000userlogin
sudo chmod u+s 3000userlogin

The chown command makes the binary owned by root, and the chmod command makes it setuid. Thus, when the program is execve'd it will have an effective user ID of root (euid=0).

Alternately, you can download the code and use the associated makefile to build by doing the following:

wget https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/tut4.tar.gz
tar xzf tut4.tar.gz
cd tut4
sudo apt install make # make isn't installed on the class VMs oops
make
make setuid

===SSH===

Install the openssh-server package (note on openstack it will already be installed, but on a default Ubuntu desktop install it won't be):

sudo apt-get install openssh-server

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Public key authentication===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

==Tasks==

# Compile and setup 3000userlogin as described above. Create a new user account. Verify that you can use 3000userlogin to login as the new user without typing the password of the new user.
# What is returned as the user's password by getpwnam()? Is this what you expected?
# Compare the uid, gid, euid, egid when running 3000userlogin as a regular user, running it setuid root, and running it as root (i.e., running it from a root shell without the setuid bit set). Also check to see what happens when you set the setgid bit (with different group IDs on the file).
# Why does 3000userlogin change its gid before changing its uid? What happens if you switch the order of these operations?
# Make 3000userlogin use the shell that is specified in the user's password entry. Check by making a new user and setting its shell to a new shell and then see if that new shell runs when you run 3000userlogin. You should change a user's shell with the chsh command, run as that user.
# Can you set 3000shell to be a user's default shell? What changes do you have to make for chsh to accept 3000shell? Does anything obvious break when running 3000shell this way, and how can you change 3000userlogin to fix it?
# Does a user's default shell have to be a regular shell? Could it instead be an arbitrary program? How do you know?
# How important is each of the environment variables that is set by 3000userlogin? Are these the only environment variables that are set after you successfully login?
# Note that 3000userlogin uses environ not envp (as an argument to main) to access environment variables. Why not use envp? (Try changing the code to use envp and see what happens.)
# Setup password-less login to your local system between the student and other account (or any two other accounts), following the above instructions. Note that the "local" account is the one you are running the ssh command on.
# Setup password-less login to access.scs.carleton.ca, following the instructions above.
# Secure shell can be used to directly run a command on another program rather than the default shell. For example, try "ssh student@localhost bc -l" and see that bc is run. When you do this, does ssh directly run the specified command or does it first run a shell and have the shell run the command? Use opensnoop.bt or execsnoop.bt to verify.
# What files in /etc does bash access when you login via 3000userlogin? How does this compare to what bash opens when you log in via ssh?
# '''(Optional):''' Prompt for the user's password before logging the user in. To do this, you'll need to get the right password hash and then figure out how to hash the entered password to check if it matches. See online guides about [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils how passwords are stored on Linux] for help.

==Code==

[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000userlogin.tar.gz Download code for this tutorial (3000userlogin.c and Makefile)]

===3000userlogin.c===

[https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/3000userlogin.c Download 3000userlogin.c]

<syntaxhighlight lang="c" line>
/* 3000userlogin.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
int result;
char *shell_argv[3];
char *username;
extern char **environ;
struct passwd *pw_entry;

if (argc < 2) {
fprintf(stderr, "Usage: %s <username>\n", argv[0]);
exit(-1);
}

printf("uid=%d, euid=%d, gid=%d, egid=%d\n",
getuid(), geteuid(), getgid(), getegid());

username = argv[1];

pw_entry = getpwnam(username);
if (pw_entry == NULL) {
fprintf(stderr, "Could not find user %s.\n", username);
exit(-2);
}

result = setgid(pw_entry->pw_gid);
if (result != 0) {
fprintf(stderr, "Failed to change to gid %d\n",
pw_entry->pw_gid);
exit(-3);
}

result = setuid(pw_entry->pw_uid);
if (result != 0) {
fprintf(stderr, "Failed to change to uid %d\n",
pw_entry->pw_uid);
exit(-4);
}

result = chdir(pw_entry->pw_dir);
if (result != 0) {
fprintf(stderr, "Failed to change to home dir %s\n",
pw_entry->pw_dir);
exit(-5);
}

shell_argv[0] = "bash";
shell_argv[1] = "--login";
shell_argv[2] = NULL;

clearenv();
setenv("USERNAME", pw_entry->pw_name, 1);
setenv("PATH", "/usr/bin:/bin", 1);
setenv("SHELL", "/bin/bash", 1);
setenv("HOME", pw_entry->pw_dir, 1);
setenv("COMP3000", "yes", 1);

execve("/bin/bash", shell_argv, environ);

fprintf(stderr, "Failed to exec bash\n");
return -6;
}
</syntaxhighlight>

===Makefile===

<syntaxhighlight lang="make" line>
.PHONY: setuid

3000userlogin: 3000userlogin.c
gcc -Wall -O 3000userlogin.c -o 3000userlogin

setuid: 3000userlogin
@echo "The following changes ownership to root, group to root, and sets the setuid bit on 3000userlogin:"
sudo chown root:root 3000userlogin && sudo chmod u+s 3000userlogin
@echo "3000userlogin is now setuid root!"
</syntaxhighlight>

Operating Systems 2026F: Tutorial 4

2026-10-04T19:07:29Z

Soma: /* File Permissions */

'''This tutorial is not yet finalized.'''

In this tutorial you will learn about permissions, accounts, how logging in works, and ssh.

==Background==

In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have been allocated to the current process.

A process is an abstraction over the limited access of the CPU's user mode. All processes run in user mode. While kernel code can be doing work on behalf of a specific process, properly speaking no kernel code is in a process. Instead, the kernel implements the process abstraction.

The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

Most users have limited access. One user, <tt>root</tt> (with user ID of 0), has as much access as is possible from a process. The kernel will even allow the root process to modify how the kernel operates. Processes running as root are still just processes, though, and any access that the kernel gives to such processes is at the discretion of the kernel. (In fact, there are setups which limit the privileges of the root user.)

===File Permissions===

A process' permission to access files in UNIX is determined by the user and group associated with that process. When a person logs in, their initial process is given the user and group associated with their account. All child processes of that initial login process inherit the same user and group.

A user can belong to multiple groups but a process only belongs to one group at a time. (There are ways to change the group associated with a process.) A file is always owned by someone and is always associated with a group. All files on the UNIX file system (including directories and other special files) have three different sets of permissions:
* owner permissions
* group permissions
* other permissions
Each of these have read, write, and/or execute permissions along with some other special permissions.

One special permission is the ''setuid'' bit. When an executable has this bit set, the process will run as the user who owns that executable (rather than as the user associated with the process that did the execve). The setuid bit is particularly important when a file is owned by root, as it gives us a way for regular users to escape the bounds of normal permissions. We will see the setuid root bit in action in this tutorial.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Logging in to a UNIX system===

In order to log in to a UNIX system (Linux or otherwise), the following steps must occur (potentially not in this order).

# The user must authenticate themselves, proving their identity and that they are allowed to access the system. By default this is done through a username and password.
# A new process, U, should be created for the authenticated user.
# The login program must establish communication with the user via some communications channel. Normally this channel will be a device. Standard in, out, and error for U should be connected to this device.
# U changes uid and gid to that of the new user.
# U sets up other aspects of the user's context (mainly setting key environment variables).
# U does an execve of the user's chosen shell.

[[#Code|3000userlogin]] is a basic implementation of steps 4-6. (Steps 2 and 3 are accomplished by running 3000userlogin in a shell, as running an external command means the shell first creates a new process, as we have seen. We are skipping 1.)

===SSH===

Secure Shell, or ssh, is the standard method for accessing UNIX and UNIX-like systems remotely. It is a more secure replacement for older technologies such as [https://en.wikipedia.org/wiki/Berkeley_r-commands rsh] and [https://en.wikipedia.org/wiki/Telnet telnet].

The standard implementation of ssh is [http://www.openssh.org openssh], a version of ssh that was originally created for [https://www.openbsd.org/ OpenBSD] but has been ported to other systems. OpenBSD has a reputation for being the most secure UNIX-like system around. It tends to be a bit harder to configure, have less support for current hardware, and have lower overall performance than Linux-based systems; however, it can be very competitive for some workloads.

While ssh support password-based authentication, it is meant to be used with more secure forms of authentication. For example, ssh supports public key authentication, a type of authentication that makes use of [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]. Instead of a shared key (such as a password) that is known to both parties, with public key cryptography, keys come in two parts: a public part and a private part. The public part should be widely distributed, while the private part needs to be carefully secured.

Public key cryptography can be used to send secret messages to anyone you can get the public key for. With digital signatures, public key cryptography can also be used to verify the authenticity and integrity of messages, so long as we know the public key of the originating party.

With public key authentication, we use a key pair to authenticate rather than sending a password.

A cool feature of public key authentication is it is possible to automatically log into a system once the appropriate private key is made available, thus giving us the convenience of passwordless logins with better security than passwords.

==Setup==

===3000userlogin===

When 3000userlogin is properly compiled and set up, you can run

./3000userlogin someuser

and you'll be logged in as "someuser", assuming someuser exists.

You can add a user with the adduser command. For example, to create the user "someuser":

sudo adduser someuser

Note you'll have to answer several questions.

If you just compile 3000userlogin normally, you won't be able to log in as anyone except the current user. To compile and set up 3000userlogin, do the following:

gcc -O -Wall 3000userlogin.c -o 3000userlogin
sudo chown root:root 3000userlogin
sudo chmod u+s 3000userlogin

The chown command makes the binary owned by root, and the chmod command makes it setuid. Thus, when the program is execve'd it will have an effective user ID of root (euid=0).

Alternately, you can download the code and use the associated makefile to build by doing the following:

wget https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/tut4.tar.gz
tar xzf tut4.tar.gz
cd tut4
make
make setuid

===SSH===

Install the openssh-server package (note on openstack it will already be installed, but on a default Ubuntu desktop install it won't be):

sudo apt-get install openssh-server

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Public key authentication===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

==Tasks==

# Compile and setup 3000userlogin as described above. Create a new user account. Verify that you can use 3000userlogin to login as the new user without typing the password of the new user.
# What is returned as the user's password by getpwnam()? Is this what you expected?
# Compare the uid, gid, euid, egid when running 3000userlogin as a regular user, running it setuid root, and running it as root (i.e., running it from a root shell without the setuid bit set). Also check to see what happens when you set the setgid bit (with different group IDs on the file).
# Why does 3000userlogin change its gid before changing its uid? What happens if you switch the order of these operations?
# Make 3000userlogin use the shell that is specified in the user's password entry. Check by making a new user and setting its shell to a new shell and then see if that new shell runs when you run 3000userlogin. You should change a user's shell with the chsh command, run as that user.
# Can you set 3000shell to be a user's default shell? What changes do you have to make for chsh to accept 3000shell? Does anything obvious break when running 3000shell this way, and how can you change 3000userlogin to fix it?
# Does a user's default shell have to be a regular shell? Could it instead be an arbitrary program? How do you know?
# How important is each of the environment variables that is set by 3000userlogin? Are these the only environment variables that are set after you successfully login?
# Note that 3000userlogin uses environ not envp (as an argument to main) to access environment variables. Why not use envp? (Try changing the code to use envp and see what happens.)
# Setup password-less login to your local system between the student and other account (or any two other accounts), following the above instructions. Note that the "local" account is the one you are running the ssh command on.
# Setup password-less login to access.scs.carleton.ca, following the instructions above.
# Secure shell can be used to directly run a command on another program rather than the default shell. For example, try "ssh student@localhost bc -l" and see that bc is run. When you do this, does ssh directly run the specified command or does it first run a shell and have the shell run the command? Use opensnoop.bt or execsnoop.bt to verify.
# What files in /etc does bash access when you login via 3000userlogin? How does this compare to what bash opens when you log in via ssh?
# '''(Optional):''' Prompt for the user's password before logging the user in. To do this, you'll need to get the right password hash and then figure out how to hash the entered password to check if it matches. See online guides about [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils how passwords are stored on Linux] for help.

==Code==

[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000userlogin.tar.gz Download code for this tutorial (3000userlogin.c and Makefile)]

===3000userlogin.c===

[https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/3000userlogin.c Download 3000userlogin.c]

<syntaxhighlight lang="c" line>
/* 3000userlogin.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
int result;
char *shell_argv[3];
char *username;
extern char **environ;
struct passwd *pw_entry;

if (argc < 2) {
fprintf(stderr, "Usage: %s <username>\n", argv[0]);
exit(-1);
}

printf("uid=%d, euid=%d, gid=%d, egid=%d\n",
getuid(), geteuid(), getgid(), getegid());

username = argv[1];

pw_entry = getpwnam(username);
if (pw_entry == NULL) {
fprintf(stderr, "Could not find user %s.\n", username);
exit(-2);
}

result = setgid(pw_entry->pw_gid);
if (result != 0) {
fprintf(stderr, "Failed to change to gid %d\n",
pw_entry->pw_gid);
exit(-3);
}

result = setuid(pw_entry->pw_uid);
if (result != 0) {
fprintf(stderr, "Failed to change to uid %d\n",
pw_entry->pw_uid);
exit(-4);
}

result = chdir(pw_entry->pw_dir);
if (result != 0) {
fprintf(stderr, "Failed to change to home dir %s\n",
pw_entry->pw_dir);
exit(-5);
}

shell_argv[0] = "bash";
shell_argv[1] = "--login";
shell_argv[2] = NULL;

clearenv();
setenv("USERNAME", pw_entry->pw_name, 1);
setenv("PATH", "/usr/bin:/bin", 1);
setenv("SHELL", "/bin/bash", 1);
setenv("HOME", pw_entry->pw_dir, 1);
setenv("COMP3000", "yes", 1);

execve("/bin/bash", shell_argv, environ);

fprintf(stderr, "Failed to exec bash\n");
return -6;
}
</syntaxhighlight>

===Makefile===

<syntaxhighlight lang="make" line>
.PHONY: setuid

3000userlogin: 3000userlogin.c
gcc -Wall -O 3000userlogin.c -o 3000userlogin

setuid: 3000userlogin
@echo "The following changes ownership to root, group to root, and sets the setuid bit on 3000userlogin:"
sudo chown root:root 3000userlogin && sudo chmod u+s 3000userlogin
@echo "3000userlogin is now setuid root!"
</syntaxhighlight>

Operating Systems 2026F: Tutorial 4

2026-10-04T19:04:07Z

Soma: /* Background */

'''This tutorial is not yet finalized.'''

In this tutorial you will learn about permissions, accounts, how logging in works, and ssh.

==Background==

In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have been allocated to the current process.

A process is an abstraction over the limited access of the CPU's user mode. All processes run in user mode. While kernel code can be doing work on behalf of a specific process, properly speaking no kernel code is in a process. Instead, the kernel implements the process abstraction.

The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

Most users have limited access. One user, <tt>root</tt> (with user ID of 0), has as much access as is possible from a process. The kernel will even allow the root process to modify how the kernel operates. Processes running as root are still just processes, though, and any access that the kernel gives to such processes is at the discretion of the kernel. (In fact, there are setups which limit the privileges of the root user.)

===File Permissions===

A process' permission to access files in UNIX is determined by the user and group associated with that process. When a person logs in, their initial process is given the user and group associated with their account. All child processes of that initial login process inherit the same user and group.

A user can belong to multiple groups but a process only belongs to one group at a time. (There are ways to change the group associated with a process.) A file is always owned by someone and is always associated with a group. All files on the UNIX file system (including directories and other special files) have three different sets of permissions:
* owner permissions
* group permissions
* other permissions
Each of these have read, write, and/or execute permissions along with some other special permissions we'll discuss later.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Logging in to a UNIX system===

In order to log in to a UNIX system (Linux or otherwise), the following steps must occur (potentially not in this order).

# The user must authenticate themselves, proving their identity and that they are allowed to access the system. By default this is done through a username and password.
# A new process, U, should be created for the authenticated user.
# The login program must establish communication with the user via some communications channel. Normally this channel will be a device. Standard in, out, and error for U should be connected to this device.
# U changes uid and gid to that of the new user.
# U sets up other aspects of the user's context (mainly setting key environment variables).
# U does an execve of the user's chosen shell.

[[#Code|3000userlogin]] is a basic implementation of steps 4-6. (Steps 2 and 3 are accomplished by running 3000userlogin in a shell, as running an external command means the shell first creates a new process, as we have seen. We are skipping 1.)

===SSH===

Secure Shell, or ssh, is the standard method for accessing UNIX and UNIX-like systems remotely. It is a more secure replacement for older technologies such as [https://en.wikipedia.org/wiki/Berkeley_r-commands rsh] and [https://en.wikipedia.org/wiki/Telnet telnet].

The standard implementation of ssh is [http://www.openssh.org openssh], a version of ssh that was originally created for [https://www.openbsd.org/ OpenBSD] but has been ported to other systems. OpenBSD has a reputation for being the most secure UNIX-like system around. It tends to be a bit harder to configure, have less support for current hardware, and have lower overall performance than Linux-based systems; however, it can be very competitive for some workloads.

While ssh support password-based authentication, it is meant to be used with more secure forms of authentication. For example, ssh supports public key authentication, a type of authentication that makes use of [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]. Instead of a shared key (such as a password) that is known to both parties, with public key cryptography, keys come in two parts: a public part and a private part. The public part should be widely distributed, while the private part needs to be carefully secured.

Public key cryptography can be used to send secret messages to anyone you can get the public key for. With digital signatures, public key cryptography can also be used to verify the authenticity and integrity of messages, so long as we know the public key of the originating party.

With public key authentication, we use a key pair to authenticate rather than sending a password.

A cool feature of public key authentication is it is possible to automatically log into a system once the appropriate private key is made available, thus giving us the convenience of passwordless logins with better security than passwords.

==Setup==

===3000userlogin===

When 3000userlogin is properly compiled and set up, you can run

./3000userlogin someuser

and you'll be logged in as "someuser", assuming someuser exists.

You can add a user with the adduser command. For example, to create the user "someuser":

sudo adduser someuser

Note you'll have to answer several questions.

If you just compile 3000userlogin normally, you won't be able to log in as anyone except the current user. To compile and set up 3000userlogin, do the following:

gcc -O -Wall 3000userlogin.c -o 3000userlogin
sudo chown root:root 3000userlogin
sudo chmod u+s 3000userlogin

The chown command makes the binary owned by root, and the chmod command makes it setuid. Thus, when the program is execve'd it will have an effective user ID of root (euid=0).

Alternately, you can download the code and use the associated makefile to build by doing the following:

wget https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/tut4.tar.gz
tar xzf tut4.tar.gz
cd tut4
make
make setuid

===SSH===

Install the openssh-server package (note on openstack it will already be installed, but on a default Ubuntu desktop install it won't be):

sudo apt-get install openssh-server

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Public key authentication===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

==Tasks==

# Compile and setup 3000userlogin as described above. Create a new user account. Verify that you can use 3000userlogin to login as the new user without typing the password of the new user.
# What is returned as the user's password by getpwnam()? Is this what you expected?
# Compare the uid, gid, euid, egid when running 3000userlogin as a regular user, running it setuid root, and running it as root (i.e., running it from a root shell without the setuid bit set). Also check to see what happens when you set the setgid bit (with different group IDs on the file).
# Why does 3000userlogin change its gid before changing its uid? What happens if you switch the order of these operations?
# Make 3000userlogin use the shell that is specified in the user's password entry. Check by making a new user and setting its shell to a new shell and then see if that new shell runs when you run 3000userlogin. You should change a user's shell with the chsh command, run as that user.
# Can you set 3000shell to be a user's default shell? What changes do you have to make for chsh to accept 3000shell? Does anything obvious break when running 3000shell this way, and how can you change 3000userlogin to fix it?
# Does a user's default shell have to be a regular shell? Could it instead be an arbitrary program? How do you know?
# How important is each of the environment variables that is set by 3000userlogin? Are these the only environment variables that are set after you successfully login?
# Note that 3000userlogin uses environ not envp (as an argument to main) to access environment variables. Why not use envp? (Try changing the code to use envp and see what happens.)
# Setup password-less login to your local system between the student and other account (or any two other accounts), following the above instructions. Note that the "local" account is the one you are running the ssh command on.
# Setup password-less login to access.scs.carleton.ca, following the instructions above.
# Secure shell can be used to directly run a command on another program rather than the default shell. For example, try "ssh student@localhost bc -l" and see that bc is run. When you do this, does ssh directly run the specified command or does it first run a shell and have the shell run the command? Use opensnoop.bt or execsnoop.bt to verify.
# What files in /etc does bash access when you login via 3000userlogin? How does this compare to what bash opens when you log in via ssh?
# '''(Optional):''' Prompt for the user's password before logging the user in. To do this, you'll need to get the right password hash and then figure out how to hash the entered password to check if it matches. See online guides about [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils how passwords are stored on Linux] for help.

==Code==

[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000userlogin.tar.gz Download code for this tutorial (3000userlogin.c and Makefile)]

===3000userlogin.c===

[https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/3000userlogin.c Download 3000userlogin.c]

<syntaxhighlight lang="c" line>
/* 3000userlogin.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
int result;
char *shell_argv[3];
char *username;
extern char **environ;
struct passwd *pw_entry;

if (argc < 2) {
fprintf(stderr, "Usage: %s <username>\n", argv[0]);
exit(-1);
}

printf("uid=%d, euid=%d, gid=%d, egid=%d\n",
getuid(), geteuid(), getgid(), getegid());

username = argv[1];

pw_entry = getpwnam(username);
if (pw_entry == NULL) {
fprintf(stderr, "Could not find user %s.\n", username);
exit(-2);
}

result = setgid(pw_entry->pw_gid);
if (result != 0) {
fprintf(stderr, "Failed to change to gid %d\n",
pw_entry->pw_gid);
exit(-3);
}

result = setuid(pw_entry->pw_uid);
if (result != 0) {
fprintf(stderr, "Failed to change to uid %d\n",
pw_entry->pw_uid);
exit(-4);
}

result = chdir(pw_entry->pw_dir);
if (result != 0) {
fprintf(stderr, "Failed to change to home dir %s\n",
pw_entry->pw_dir);
exit(-5);
}

shell_argv[0] = "bash";
shell_argv[1] = "--login";
shell_argv[2] = NULL;

clearenv();
setenv("USERNAME", pw_entry->pw_name, 1);
setenv("PATH", "/usr/bin:/bin", 1);
setenv("SHELL", "/bin/bash", 1);
setenv("HOME", pw_entry->pw_dir, 1);
setenv("COMP3000", "yes", 1);

execve("/bin/bash", shell_argv, environ);

fprintf(stderr, "Failed to exec bash\n");
return -6;
}
</syntaxhighlight>

===Makefile===

<syntaxhighlight lang="make" line>
.PHONY: setuid

3000userlogin: 3000userlogin.c
gcc -Wall -O 3000userlogin.c -o 3000userlogin

setuid: 3000userlogin
@echo "The following changes ownership to root, group to root, and sets the setuid bit on 3000userlogin:"
sudo chown root:root 3000userlogin && sudo chmod u+s 3000userlogin
@echo "3000userlogin is now setuid root!"
</syntaxhighlight>

Operating Systems 2026F: Tutorial 4

2026-10-04T19:01:09Z

Soma: Created page with "'''This tutorial is not yet finalized.''' In this tutorial you will learn about permissions, accounts, how logging in works, and ssh. ==Background== In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have be..."

'''This tutorial is not yet finalized.'''

In this tutorial you will learn about permissions, accounts, how logging in works, and ssh.

==Background==

In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have been allocated to the current process.

A process is an abstraction over the limited access of the CPU's user mode. All processes run in user mode. While kernel code can be doing work on behalf of a specific process, properly speaking no kernel code is in a process. Instead, the kernel implements the process abstraction.

The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

===File Permissions===

A process' permission to access files in UNIX is determined by the user and group associated with that process. When a person logs in, their initial process is given the user and group associated with their account. All child processes of that initial login process inherit the same user and group.

A user can belong to multiple groups but a process only belongs to one group at a time. (There are ways to change the group associated with a process.) A file is always owned by someone and is always associated with a group. All files on the UNIX file system (including directories and other special files) have three different sets of permissions:
* owner permissions
* group permissions
* other permissions
Each of these have read, write, and/or execute permissions along with some other special permissions we'll discuss later.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Logging in to a UNIX system===

In order to log in to a UNIX system (Linux or otherwise), the following steps must occur (potentially not in this order).

# The user must authenticate themselves, proving their identity and that they are allowed to access the system. By default this is done through a username and password.
# A new process, U, should be created for the authenticated user.
# The login program must establish communication with the user via some communications channel. Normally this channel will be a device. Standard in, out, and error for U should be connected to this device.
# U changes uid and gid to that of the new user.
# U sets up other aspects of the user's context (mainly setting key environment variables).
# U does an execve of the user's chosen shell.

[[#Code|3000userlogin]] is a basic implementation of steps 4-6. (Steps 2 and 3 are accomplished by running 3000userlogin in a shell, as running an external command means the shell first creates a new process, as we have seen. We are skipping 1.)

===SSH===

Secure Shell, or ssh, is the standard method for accessing UNIX and UNIX-like systems remotely. It is a more secure replacement for older technologies such as [https://en.wikipedia.org/wiki/Berkeley_r-commands rsh] and [https://en.wikipedia.org/wiki/Telnet telnet].

The standard implementation of ssh is [http://www.openssh.org openssh], a version of ssh that was originally created for [https://www.openbsd.org/ OpenBSD] but has been ported to other systems. OpenBSD has a reputation for being the most secure UNIX-like system around. It tends to be a bit harder to configure, have less support for current hardware, and have lower overall performance than Linux-based systems; however, it can be very competitive for some workloads.

While ssh support password-based authentication, it is meant to be used with more secure forms of authentication. For example, ssh supports public key authentication, a type of authentication that makes use of [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]. Instead of a shared key (such as a password) that is known to both parties, with public key cryptography, keys come in two parts: a public part and a private part. The public part should be widely distributed, while the private part needs to be carefully secured.

Public key cryptography can be used to send secret messages to anyone you can get the public key for. With digital signatures, public key cryptography can also be used to verify the authenticity and integrity of messages, so long as we know the public key of the originating party.

With public key authentication, we use a key pair to authenticate rather than sending a password.

A cool feature of public key authentication is it is possible to automatically log into a system once the appropriate private key is made available, thus giving us the convenience of passwordless logins with better security than passwords.

==Setup==

===3000userlogin===

When 3000userlogin is properly compiled and set up, you can run

./3000userlogin someuser

and you'll be logged in as "someuser", assuming someuser exists.

You can add a user with the adduser command. For example, to create the user "someuser":

sudo adduser someuser

Note you'll have to answer several questions.

If you just compile 3000userlogin normally, you won't be able to log in as anyone except the current user. To compile and set up 3000userlogin, do the following:

gcc -O -Wall 3000userlogin.c -o 3000userlogin
sudo chown root:root 3000userlogin
sudo chmod u+s 3000userlogin

The chown command makes the binary owned by root, and the chmod command makes it setuid. Thus, when the program is execve'd it will have an effective user ID of root (euid=0).

Alternately, you can download the code and use the associated makefile to build by doing the following:

wget https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/tut4.tar.gz
tar xzf tut4.tar.gz
cd tut4
make
make setuid

===SSH===

Install the openssh-server package (note on openstack it will already be installed, but on a default Ubuntu desktop install it won't be):

sudo apt-get install openssh-server

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Public key authentication===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

==Tasks==

# Compile and setup 3000userlogin as described above. Create a new user account. Verify that you can use 3000userlogin to login as the new user without typing the password of the new user.
# What is returned as the user's password by getpwnam()? Is this what you expected?
# Compare the uid, gid, euid, egid when running 3000userlogin as a regular user, running it setuid root, and running it as root (i.e., running it from a root shell without the setuid bit set). Also check to see what happens when you set the setgid bit (with different group IDs on the file).
# Why does 3000userlogin change its gid before changing its uid? What happens if you switch the order of these operations?
# Make 3000userlogin use the shell that is specified in the user's password entry. Check by making a new user and setting its shell to a new shell and then see if that new shell runs when you run 3000userlogin. You should change a user's shell with the chsh command, run as that user.
# Can you set 3000shell to be a user's default shell? What changes do you have to make for chsh to accept 3000shell? Does anything obvious break when running 3000shell this way, and how can you change 3000userlogin to fix it?
# Does a user's default shell have to be a regular shell? Could it instead be an arbitrary program? How do you know?
# How important is each of the environment variables that is set by 3000userlogin? Are these the only environment variables that are set after you successfully login?
# Note that 3000userlogin uses environ not envp (as an argument to main) to access environment variables. Why not use envp? (Try changing the code to use envp and see what happens.)
# Setup password-less login to your local system between the student and other account (or any two other accounts), following the above instructions. Note that the "local" account is the one you are running the ssh command on.
# Setup password-less login to access.scs.carleton.ca, following the instructions above.
# Secure shell can be used to directly run a command on another program rather than the default shell. For example, try "ssh student@localhost bc -l" and see that bc is run. When you do this, does ssh directly run the specified command or does it first run a shell and have the shell run the command? Use opensnoop.bt or execsnoop.bt to verify.
# What files in /etc does bash access when you login via 3000userlogin? How does this compare to what bash opens when you log in via ssh?
# '''(Optional):''' Prompt for the user's password before logging the user in. To do this, you'll need to get the right password hash and then figure out how to hash the entered password to check if it matches. See online guides about [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils how passwords are stored on Linux] for help.

==Code==

[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000userlogin.tar.gz Download code for this tutorial (3000userlogin.c and Makefile)]

===3000userlogin.c===

[https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/3000userlogin.c Download 3000userlogin.c]

<syntaxhighlight lang="c" line>
/* 3000userlogin.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
int result;
char *shell_argv[3];
char *username;
extern char **environ;
struct passwd *pw_entry;

if (argc < 2) {
fprintf(stderr, "Usage: %s <username>\n", argv[0]);
exit(-1);
}

printf("uid=%d, euid=%d, gid=%d, egid=%d\n",
getuid(), geteuid(), getgid(), getegid());

username = argv[1];

pw_entry = getpwnam(username);
if (pw_entry == NULL) {
fprintf(stderr, "Could not find user %s.\n", username);
exit(-2);
}

result = setgid(pw_entry->pw_gid);
if (result != 0) {
fprintf(stderr, "Failed to change to gid %d\n",
pw_entry->pw_gid);
exit(-3);
}

result = setuid(pw_entry->pw_uid);
if (result != 0) {
fprintf(stderr, "Failed to change to uid %d\n",
pw_entry->pw_uid);
exit(-4);
}

result = chdir(pw_entry->pw_dir);
if (result != 0) {
fprintf(stderr, "Failed to change to home dir %s\n",
pw_entry->pw_dir);
exit(-5);
}

shell_argv[0] = "bash";
shell_argv[1] = "--login";
shell_argv[2] = NULL;

clearenv();
setenv("USERNAME", pw_entry->pw_name, 1);
setenv("PATH", "/usr/bin:/bin", 1);
setenv("SHELL", "/bin/bash", 1);
setenv("HOME", pw_entry->pw_dir, 1);
setenv("COMP3000", "yes", 1);

execve("/bin/bash", shell_argv, environ);

fprintf(stderr, "Failed to exec bash\n");
return -6;
}
</syntaxhighlight>

===Makefile===

<syntaxhighlight lang="make" line>
.PHONY: setuid

3000userlogin: 3000userlogin.c
gcc -Wall -O 3000userlogin.c -o 3000userlogin

setuid: 3000userlogin
@echo "The following changes ownership to root, group to root, and sets the setuid bit on 3000userlogin:"
sudo chown root:root 3000userlogin && sudo chmod u+s 3000userlogin
@echo "3000userlogin is now setuid root!"
</syntaxhighlight>

Operating Systems 2026F Lecture 6

2026-10-02T14:02:07Z

Soma: Created page with "==Video== Video from the lecture given on October 2, 2026 is now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec06-20261002.mp4 Lecture 6] ==Notes== ===Lecture 6=== <pre> Lecture 6 --------- Signals What is a signal? - message from the kernel to a process - can originate from the kernel or from another process Idea: interrupt the process to handle an event - so a simple form of event handling, or more exception handl..."

==Video==

Video from the lecture given on October 2, 2026 is now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec06-20261002.mp4 Lecture 6]

==Notes==

===Lecture 6===

<pre>
Lecture 6
---------

Signals

What is a signal?
- message from the kernel to a process
- can originate from the kernel or from another process

Idea: interrupt the process to handle an event
- so a simple form of event handling, or more exception handling

When a process receives a signal
- it stops executing the current code (function)
- it instead starts running the appropriate signal handler
- when handling is complete, it then returns to where it was, continuing the function

This means signals can interrupt almost ANY part of your program
- need to be prepared!

What sort of signals are there?
- user defined (SIGUSR1, SIGUSR2)
- memory access errors (SIGSEGV, SIGBUS)
- some floating point errors

But mainly:
- when child processes terminate (SIGCHLD)
- when the user wants to terminate the process (SIGTERM)
or suspend (SIGSTOP)

And many other conditions

Signal handlers are defined by default by the C library

you can change signals with sigaction()
(don't use signal)

So what bad things can happen to your program because of a signal handler?
- could interrupt critical code
- can even happen while doing a system call
- handler could mess up state of your code

When a process receives a signal while in a system call, we have two choices:
- continue the system call after the signal is handled
- that doesn't work because of how the kernel operates
- but we can do the system call from the beginning (restart it)
- cancel the system call after the signal is handled

Standard I/O file descriptors
- when you type "ls", its output goes to the terminal
- but all ls was doing was writing to standard out
- how did standard out end up in the terminal?

C standard in = file descriptor 0 in Linux/UNIX
C standard out = file descriptor 1 in Linux/UNIX
C standard error = file descriptor 2 in Linux/UNIX

What is a file descriptor?
- small number
- refers to an open file

A file descriptor is what UNIX uses instead of the FILE struct for C.

But what is that small number, really?
- index into an array of open files the kernel maintains
for the currently running process

When a program starts, 0, 1, and 2 file descriptors are expected to be open and ready to go, with 0 ready for reads and 1 and 2 ready for writes.

Who gets these file descriptors set up? Whomever did the execve!
- they could inherit them from who execve'd them, but they are responsible

When you're using a shell, the shell is responsible for setting up the standard I/O file descriptors.

This is good, because it lets us do I/O redirection

So what does ">" do in most shells?
- redirects standard output to the given file

Remember that "files" in UNIX can be stored on disk, but they can be many other things as well
- tty's/pseudo tty's
- another process (IPC, inter-process communication)
</pre>

Operating Systems 2026F: Assignment 1

2026-09-30T23:34:26Z

Soma:

Please submit the answers to the following questions via Brightspace by October 5, 2026. There are 20 points in eight questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-a1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

Operating Systems 2026F: Assignment 1

2026-09-27T20:31:15Z

Soma:

Please submit the answers to the following questions via Brightspace by October 5, 2026. There are 20 points in eight questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

Operating Systems 2026F: Tutorial 3

2026-09-26T23:43:18Z

Soma: Created page with "In this tutorial you will be experimenting with and extending [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] (listed below). '''Make sure you use the original code from 3000shell for each question.''' ==Getting Started== You should download [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] on your openstack instance (or a Ubuntu Linux 21.04 system or similar). Compile it using the command gcc -O -g -..."

In this tutorial you will be experimenting with and extending [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] (listed below).

'''Make sure you use the original code from 3000shell for each question.'''

==Getting Started==

You should download [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] on your openstack instance (or a Ubuntu Linux 21.04 system or similar). Compile it using the command
gcc -O -g -Wall 3000shell.c -o 3000shell

==Standard I/O==

Recall that the shell is a command interpreter (program). In comparison, a terminal is a device used to enter data into and display data from a computer. It used to be physical - [https://en.wikipedia.org/wiki/Teleprinter teletypes, or "TTY"'s]. Today they are virtual - pseudoterminals, pseudo teletypes, or pts's. /dev/pts/1 is a pts for example. By themselves, a pts does nothing; however, they allow any program to appear as a virtual teletype to any other program. (To learn more, <tt>man ptmx</tt>. However, this goes into more detail than you need for this tutorial.)

When you ssh to a system interactively, the remote ssh process uses a pseudo tty to connect network I/O with the programs you run at the command line. In this context you can thus think of ssh (plus a pseudo tty) as an adaptor that converts network traffic into terminal-like I/O.

Standard input, (e.g., /dev/stdin), output (e.g., /dev/stdout) and error (/dev/stderr) are just
references to file descriptors 0, 1, and 2 for the current process. They can refer to basically any file. If a process is run in a terminal, stdin, stdout, and stderr are set to refer to the terminal's I/O channels via a tty or pts.

Shells provide easy interfaces for changing these file descriptors. For example:

ls > ls.log

Will redirect ls's standard output to the file ls.log. Similarly,

bc -l < math.txt

will take math input from /tmp/math.txt and output it to the current terminal. We can also use the pipe operator to direct the standard output of one program to the standard input of another:

ls -l | less

(This is really good if you have lots of files in a directory.)

Part of the magic of UNIX is that it allows problems to be solved by combining multiple programs together. For example, to get a list of unique words in a file, you can do something like the following:

tr ' \t' '\n' < file.txt | tr -d ',.!()?-' | sort | uniq | less

In summary, shells run in terminals, and the terminal interface is implemented by teletype-like devices, either a "tty" or "pts" device. Standard in, out, and error are abstractions for interactions with such terminals or, with I/O redirection, other arbitrary files.

==Tasks/Questions==

The purpose of the following questions and tasks is to help you understand how 3000shell works. At the end of this you should have an understanding of every function and every line of the code. If you understand 3000shell, then you understand the basics of all UNIX shells. Your understanding of the code will be tested later, so use this opportunity to dive deep into the code. These tasks and questions should help you build up a mental model of how 3000shell works.

# Compile and run 3000shell.c
# Try running programs in the background using & after commands entered in 3000shell. What happens to the input and output of the program? Try this for simple programs like ls and bc. Then, try it for more complex interactive programs such as nano and top.
# You may have trouble interacting with the shell after running programs in the background. How can you recover from such a situation?
# Run 3000shell under gdb and observe all the system calls it makes using <tt>catch syscall</tt> (after setting a breakpoint on main so you don't see the syscalls when it starts). Where does each system call happen? In what context (source and assembly)? Consider both parent and child processes (by setting follow-fork-mode to parent and child). Compare with the output of <tt>strace</tt> (e.g., run <tt>strace -fqo 3000shell.log ./3000shell</tt>). For info on gdb, see the [[GDB quick start]].
# 3000shell implements a simple form of output redirection. What syntax should you use to redirect standard output to a file?
# Why are lines 207-210 there (the check for pid == -1)?
# Make find_binary show every attempt to find a binary.
# Make the shell output "Ouch!" when you send it a SIGUSR1 signal.
# Delete line 324 (SA_RESTART). How does the behavior of 3000shell change?
# Replace the use of find_env() with getenv(). How do their interfaces differ?
# Make plist output the parent process id for each process, e.g. "5123 ls (5122)". Pay attention to the stat and status files in the per-process directories in /proc.
# Implement redirection of standard error
# Implement redirection of standard out for plist() (the same as if it was an external command).
# Implement a built-in 3000kill command that works like the standard kill command. (What system call/library call is used to send signals?)

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c]===

<syntaxhighlight lang="c" line>
/* 3000shell.c */
/* v2 Sept. 15, 2019 */
/* v1 Sept. 24, 2017 */
/* based off of csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html */
/* Original under "BSD" license */
/* This version is under GPLv3, copyright 2017, 2019 Anil Somayaji */
/* You really shouldn't be incorporating parts of this in any other code,
it is meant for teaching, not production */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <dirent.h>
#include <ctype.h>
#include <fcntl.h>
#include <signal.h>

#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16
#define COMM_SIZE 32

const char *proc_prefix = "/proc";

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp, *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if (strlen(buf_args[i]) > 0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

/* this is kind of like getenv() */
char *find_env(char *envvar, char *notfound, char *envp[])
{
const int MAXPATTERN = 128;
int i, p;
char c;
char pattern[MAXPATTERN];
char *value = NULL;

p = 0;
while ((c = envvar[p])) {
pattern[p] = c;
p++;
if (p == (MAXPATTERN - 2)) {
break;
}
}
pattern[p] = '=';
p++;
pattern[p] = '\0';

i = 0;
while (envp[i] != NULL) {
if (strncmp(pattern, envp[i], p) == 0) {
value = envp[i] + p;
}
i++;
}

if (value == NULL) {
return notfound;
} else {
return value;
}
}

void find_binary(char *name, char *path, char *fn, int fn_size) {
char *n, *p;
int r, stat_return;

struct stat file_status;

if (name[0] == '.' || name[0] == '/') {
strncpy(fn, name, fn_size);
return;
}

p = path;
while (*p != '\0') {
r = 0;
while (*p != '\0' && *p != ':' && r < fn_size - 1) {
fn[r] = *p;
r++;
p++;
}

fn[r] = '/';
r++;

n = name;
while (*n != '\0' && r < fn_size) {
fn[r] = *n;
n++;
r++;
}
fn[r] = '\0';

stat_return = stat(fn, &file_status);

if (stat_return == 0) {
return;
}

if (*p != '\0') {
p++;
}
}
}

void setup_comm_fn(char *pidstr, char *comm_fn)
{
char *c;

strcpy(comm_fn, proc_prefix);
c = comm_fn + strlen(comm_fn);
*c = '/';
c++;
strcpy(c, pidstr);
c = c + strlen(pidstr);
strcpy(c, "/comm");
}

void plist()
{
DIR *proc;
struct dirent *e;
int result;
char comm[COMM_SIZE]; /* seems to just need 16 */
char comm_fn[512];
int fd, i, n;

proc = opendir(proc_prefix);

if (proc == NULL) {
fprintf(stderr, "ERROR: Couldn't open /proc.\n");
}

for (e = readdir(proc); e != NULL; e = readdir(proc)) {
if (isdigit(e->d_name[0])) {
setup_comm_fn(e->d_name, comm_fn);
fd = open(comm_fn, O_RDONLY);
if (fd > -1) {
n = read(fd, comm, COMM_SIZE);
close(fd);
for (i=0; i < n; i++) {
if (comm[i] == '\n') {
comm[i] = '\0';
break;
}
}
printf("%s: %s\n", e->d_name, comm);
} else {
printf("%s\n", e->d_name);
}
}
}

result = closedir(proc);
if (result) {
fprintf(stderr, "ERROR: Couldn't close /proc.\n");
}
}

void signal_handler(int the_signal)
{
int pid, status;

if (the_signal == SIGHUP) {
fprintf(stderr, "Received SIGHUP.\n");
return;
}

if (the_signal != SIGCHLD) {
fprintf(stderr, "Child handler called for signal %d?!\n",
the_signal);
return;
}

pid = wait(&status);

if (pid == -1) {
/* nothing to wait for */
return;
}

if (WIFEXITED(status)) {
fprintf(stderr, "\nProcess %d exited with status %d.\n",
pid, WEXITSTATUS(status));
} else {
fprintf(stderr, "\nProcess %d aborted.\n", pid);
}
}

void run_program(char *args[], int background, char *stdout_fn,
char *path, char *envp[])
{
pid_t pid;
int fd, *ret_status = NULL;
char bin_fn[BUFFER_SIZE];

pid = fork();
if (pid) {
if (background) {
fprintf(stderr,
"Process %d running in the background.\n",
pid);
} else {
pid = wait(ret_status);
}
} else {
find_binary(args[0], path, bin_fn, BUFFER_SIZE);

if (stdout_fn != NULL) {
fd = creat(stdout_fn, 0666);
dup2(fd, 1);
close(fd);
}

if (execve(bin_fn, args, envp)) {
puts(strerror(errno));
exit(127);
}
}
}

void prompt_loop(char *username, char *path, char *envp[])
{
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int background;
size_t nargs;
char *s;
int i, j;
char *stdout_fn;

while(1){
printf("%s $ ", username);
s = fgets(buffer, BUFFER_SIZE, stdin);

if (s == NULL) {
/* we reached EOF */
printf("\n");
exit(0);
}

parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;

if (!strcmp(args[0], "exit")) {
exit(0);
}

if (!strcmp(args[0], "plist")) {
plist();
continue;
}

background = 0;
if (strcmp(args[nargs-1], "&") == 0) {
background = 1;
nargs--;
args[nargs] = NULL;
}

stdout_fn = NULL;
for (i = 1; i < nargs; i++) {
if (args[i][0] == '>') {
stdout_fn = args[i];
stdout_fn++;
printf("Set stdout to %s\n", stdout_fn);
for (j = i; j < nargs - 1; j++) {
args[j] = args[j+1];
}
nargs--;
args[nargs] = NULL;
break;
}
}

run_program(args, background, stdout_fn, path, envp);
}
}

int main(int argc, char *argv[], char *envp[])
{
struct sigaction signal_handler_struct;

char *username;
char *default_username = "UNKNOWN";

char *path;
char *default_path = "/usr/bin:/bin";

memset (&signal_handler_struct, 0, sizeof(signal_handler_struct));
signal_handler_struct.sa_handler = signal_handler;
signal_handler_struct.sa_flags = SA_RESTART;

if (sigaction(SIGCHLD, &signal_handler_struct, NULL)) {
fprintf(stderr, "Couldn't register SIGCHLD handler.\n");
}

if (sigaction(SIGHUP, &signal_handler_struct, NULL)) {
fprintf(stderr, "Couldn't register SIGHUP handler.\n");
}

username = find_env("USER", default_username, envp);
path = find_env("PATH", default_path, envp);

prompt_loop(username, path, envp);

return 0;
}
</syntaxhighlight>

Operating Systems (Fall 2026)

2026-09-26T16:50:26Z

Soma: /* Tutorials */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
'''No class ([https://www.nspw.org NSPW])''' (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] '''No class on Oct 1 ([https://www.nspw.org NSPW])'''

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 10|Midterm Review]]

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
'''Midterm Exam (in class)'''

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 15, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems (Fall 2026)

2026-09-26T16:48:45Z

Soma: /* Assignments */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
'''No class ([https://www.nspw.org NSPW])''' (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] '''No class on Oct 1 ([https://www.nspw.org NSPW])'''

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 10|Midterm Review]]

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
'''Midterm Exam (in class)'''

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 15, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems (Fall 2026)

2026-09-26T16:48:22Z

Soma: /* Lectures & Exams */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
'''No class ([https://www.nspw.org NSPW])''' (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] '''No class on Oct 1 ([https://www.nspw.org NSPW])'''

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 10|Midterm Review]]

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
'''Midterm Exam (in class)'''

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems (Fall 2026) Course Outline

2026-09-26T16:47:35Z

Soma: /* Grading */

==Course Information==

*'''Course Number:''' COMP 3000
*'''Term:''' Fall 2026
*'''Title:''' Operating Systems
*'''Institution:''' Carleton University, School of Computer Science
*'''Instructor:''' [https://people.scs.carleton.ca/~soma Anil Somayaji] (he/him, anilsomayaji at cunet.carleton.ca): by appointment in 5137 HP and online
*'''Teaching Assistants:'''
** TAs will be announced in the first class
*'''Lectures:'''
** A: Tue. & Thu. 14:35-15:55
** B: Wed. & Fri. 8:35-9:55
*'''Tutorials:'''
** A1: Wed. 13:05-14:25
** A2: Thu. 19:35-20:55
** A3: Mon. 16:05-17:25
** B1: Mon. 14:35-15:55
** B2: Tue. 18:05-19:25
** B3: Thu. 16:05-17:25
*'''Course Website''': https://homeostasis.scs.carleton.ca/wiki/index.php/Operating_Systems_%28Fall_2026%29

For information about Carleton's academic year, including registration and withdrawal dates, see [https://calendar.carleton.ca/academicyear/ Carleton's The Academic Year].

==Course Calendar Description==

Operating system implementation course stressing fundamental issues in design and how they relate to modern computer architectures. Assignments involve the modification and extension of a multitasking operating system.

Includes: Experiential Learning Activity

Precludes additional credit for SYSC 4001. 
Prerequisites: COMP 2401 with a minimum grade of C- and COMP 2402.

==Learning Outcomes==

By the end of this course, students should:
* be able to write C code that uses low-level Linux services and should be able to implement simple Linux kernel extensions (modules),
* have a strong conceptual model of how an operating system works that allows them to determine the relative role of application and operating system code when debugging software, and
* understand the basic use and architecture of virtual machine-based cloud architectures.

Note that in order to achieve these objectives students should come into this course with a strong background in C programming and general application development.

==Topics==

Below is an approximate list of topics the course will cover. Because the concepts of operating systems are highly interconnected, many topics will be covered multiple times at increasing levels of detail. A more detailed list along with associated learning materials will be developed through the term on the [[Operating Systems (Fall 2026)|main course webpage]].

* Processes
* Computer architecture
* Filesystems
* Concurrency
* CPU Scheduling
* Virtual Memory
* Inter-Process Communication
* Networking
* High performance I/O
* Virtual Machines
* Containers
* Security
* Cloud Infrastructure

==Grading==

The marking scheme for this course is:

* 5% for lecture participation.
* 20% for tutorial participation.
* 20% for the assignments, if exam average is not too low (see below).
* 20% for the Midterm Exam, <del>Oct. 15th & 16th</del> Oct. 20th & 21st during class.
* 35% for the Final Exam (during the final exam period).

Note the following:
* The midterm and final exams are closed book: no notes, no collaboration, no online resources, no AI. Exams will be written in an exam book based on printed exams, except where accommodations require other forms. I reserve the right to give an oral exam for deferred exams.
* The lecture and tutorial participation are fundamentally graded on a credit/no credit basis. In other words, if you show up and try you should be able to get full credit. Depending upon class performance the requirements for what is required to get full credit may change over the course of the semester; however, the expectation is that everyone who tries should be able to get 100% of these marks.
* If your assignment average is more than 25% higher than your weighted exam average (midterm & final), assignment grades are dropped and the weight assigned to the exams. For example, if you get 100% on assignments but only 70% for the exams (weighted average), the assignments would no longer count towards your final grade. (Missed exams count as a zero for grade calculation purposes.)
* Late assignments are only accepted until solutions are posted, unless extenuating circumstances apply and have been discussed with the course instructor. You have to get your tutorial marked by a TA within 8 days of the tutorial being posted, again unless extenuating circumstances apply.

I also calculate grades using alternative marking schemes at the end of the semester, assigning the highest grade for each student from any of the marking schemes. Thus your final grade may be higher than might be suggested by strict following of the above scheme.

==Communication, Lectures, and Assignments==

[[Operating Systems (Fall 2026)|The course website page listed above]] is the canonical source of information on this course. Please refer to it for updates. When significant changes are made to this document it will be either announced in lecture and/or posted in the course discussion forum.

Online course announcements and discussions will be on [https://teams.microsoft.com Microsoft Teams]. While you may discuss assignments there, do not post outright answers to them (unless the solutions have been posted). You may discuss tutorials freely, as they are graded on a participation basis. Note that solutions are never posted for tutorials.

I am best contacted via Teams direct message. I will also respond to email, preferably to my CUNET address.

Assignment and exam submissions will be through [https://brightspace.carleton.ca Brightspace]. Grades will also be posted there.

All lectures will be conducted in person except when announced otherwise, in which case they will take place over Zoom. Note that the Wednesday and Friday lectures will be repeat performances of the Tuesday and Thursday lectures, except for the first week of class when they are reversed.

Lecture recordings will be posted to the course webpage, generally within 48 hours of lecture. One or both of the lectures may be posted, depending on the week.

Lecture participation is based on interactions during lecture, such as questions asked and participation in online polls. You do not need to participate in every lecture to get full marks for this; the grade is based on the quality and quantity of your interactions. Note that grades will be calculated so that lecture participation can only improve your grade.

==Tutorials==

Tutorials are graded based on participation and effort, not correctness. They are marked out of four points. The expectation is that if you make a reasonable attempt at all parts of the tutorial, you will get 4/4 points. Thus for most students tutorials are an easy way to improve your overall grade. However, if you don't do the tutorials, you can significantly harm your grade for the course.

To get credit for tutorials, you must demonstrate to your assigned TA that you have made a reasonable attempt at the questions. This demonstration will typically be through a brief conversation where you show your TA your work, either in person or virtually. Normally this conversation should happen during your assigned tutorial time but may also take place during TA office hours. If this conversation is not feasible, at your TA's discretion you may submit written answers.

The scheduled tutorial time is a designated time when you can work with TAs and other students together, in person, on that week's tutorial. TAs will generally also be available online during these times as well, so if you aren't on campus you can still get help and get credit. You can only get credit for a tutorial within 8 days of the tutorial being made available. (Tutorials are posted generally on Sundays, so you have until the end of the following Monday to get credit.) Partial attempts may be given partial credit; however, you may improve your tutorial mark as long as it is still being accepted. Exceptions will be made only if there are extenuating circumstances.

Plan to take a 2-5 hours each week to do the assigned tutorial. The Teams tutorial channel is a forum for getting help with tutorials, potentially from other students. While you may collaborate with others and use outside resources (including AI), when asked you should indicate who helped you and and the sources you used. When submitting written answers, collaborators and sources should be clearly listed.

Your work should be your own. Please don't represent the work of others as your own, because if you do, you are subject to being reported to the Dean for plagiarism.

==Collaboration==

Collaboration on all work is allowed except for the midterm and final. Collaboration, however, should be clearly acknowledged. See below for further details.

For assignments, while you may get help from others and even collaboratively solve technical problems, the code and answers submitted should all be your own work. For example, you ''may not'' divide an assignment into parts, give a part to another student or anyone else to solve, and then submit that work as your own. You have to have participated in the creation of every part of your submitted work. An easy way to make sure this happens is never share files regarding coursework or copy and paste answers into email. Instead, meet together to work on an assignment and then separate to write up your solutions.

AIs should be treated the same as human collaborators, in that you may use them, but the answers you submit should be your own work, whether it is code or text. Note that artificially boosting your assignment grades may not be helpful if there is too much of a discrepancy between them and your exam grades (see [[#Grading|Grading]] above).

Similarity between submitted assignments and projects that has not been appropriately documented will be treated as plagiarism - the same as copying on a midterm or a final - and will be submitted to the Dean for disciplinary action.

All exams are expected to be completed individually, and without electronic aid; any communication or access of electronic devices (e.g. cellphones) during exams will be considered cheating. Use of Smart Glasses (or other similar assistive technologies) before or during a test is strictly prohibited and is considered an academic integrity violation. Even if you have prescription glasses with assistive technologies, you will not be allowed to use them during the test, so please make sure that you have acceptable prescription glasses. The proctor has the right to ask to inspect your glasses before or during the test. In addition, unless authorized with PMC accommodations, you are NOT allowed to use headphones nor ear buds during a test. Also, during a test, if you choose to wear a baseball cap, sunglasses or anything else that would prevent a proctor from monitoring where your eyes are focused during the test, you will likely be asked by a proctor to move to a different seat. Lastly, you must submit your exam before leaving the classroom or it won't be graded.

==Course Notes/Multimedia==

Video from lectures will be available via the [[Operating Systems (Fall 2026)|lecture pages on the main course website]] generally within two days after lectures are delivered. These same pages will also contain code and notes given in class.

Do not rely upon the lectures and notes to cover all material related to this class. Mastery of the tutorial material is essential for doing well on the assignments and exams. Textbook and other outside readings should be used as supplements to help you understand concepts covered in lecture and tutorial.

==Required Textbooks==

The course will be using the textbook [https://www.wiley.com/en-us/operating-system-concepts-10th-edition-p-9781119320913 Operating System Concepts, 10th Edition by Silberschatz, Galvin, & Gagne]. You should plan to read the assigned sections BEFORE class, at least briefly, so you are familiar with the context of the lecture; then, read the sections in more detail after lecture.

You may also wish to consult the free online textbook [http://pages.cs.wisc.edu/~remzi/OSTEP/ Operating Systems: Three Easy Pieces]. I used this textbook in previous runs of this class.

This course focuses much more on reading code rather than writing code. Thus, John Aycock's book, [http://pages.cpsc.ucalgary.ca/~aycock/reading-and-modifying-code.pdf Reading and Modifying Code], is worth reading to better understand how reading code differs from writing code.

==Course Software==

In this course we will be working with the [http://www.ubuntu.com/ Ubuntu] Linux distribution. You may use other Linux distributions in the tutorials to complete the assigned work; there will be differences, however, in some aspects (such as installing software), particularly if you use a distribution not based on Ubuntu or Debian.

==Undergraduate Academic Advisor==

The Undergraduate Advisors for the School of Computer Science are available in Room 5302HP; or by email at (scs.ug.advisor at cunet.carleton.ca). The undergraduate advisors can assist with information about prerequisites and preclusions, course substitutions/equivalencies, understanding your academic audit and the remaining requirements for graduation. The undergraduate advisors will also refer students to appropriate resources such as the Science Student Success Centre, Learning Support Services and Writing Tutorial Services.

==SCS Computer Laboratory==

Students taking a COMP course can access the SCS computer labs. The lab schedule and location can be found at: https://carleton.ca/scs/tech-support/computer-laboratories/. All SCS computer lab and technical support information can be found at: https://carleton.ca/scs/tech-support/. Technical support staff may be contacted in-person or virtually, see this page for details: https://carleton.ca/scs/tech-support/contact-it-support/.

==Extenuating Circumstances==

While I expect you to take this course seriously, I do not expect it to be the most important thing in your life. Physical and mental health issues, family responsibilities, natural and personal disasters, and other factors may come up over the semester. I want you to succeed in this course, and to that end I will do what I reasonably can to help you succeed. If your request can be accommodated with not unreasonable effort by me or the TAs, and the accommodation is one that is reasonable to give to anyone in your circumstances, I will do what I can.

Having said this, the main thing I have to give is extra time, but there is only so much time in a semester. Sometimes you'll need to get extra time by trying again in another semester, and that is okay. Having said that, I will always respect you enough to not pressure you to make a specific choice; you must decide what is best for your circumstances.

Remember that sometimes we all need help. [https://wellness.carleton.ca/ The Carleton Wellness Website] is a good resource if you aren't sure what to do next.

==Academic Accommodations and Regulations==

===Academic Accommodation===

Carleton is committed to providing academic accessibility for all individuals. You may need special arrangements to meet your academic obligations during the term. The accommodation request processes are outlined on the Academic Accommodations website (https://students.carleton.ca/course-outline/).

===Generative AI Usage===

As our understanding of the uses of AI and its relationship to student work and academic Integrity continue to evolve, students are required to discuss their use of AI in any circumstance not described here with the course instructor to ensure it supports the learning goals for the course.

===Academic Integrity===

Students are expected to uphold the values of academic integrity, which include fairness, honesty, trust, and responsibility. Examples of actions that compromise these values include but are not limited to plagiarism, accessing unauthorized sites for assignments or tests, unauthorized collaboration on assignments or exams, and using artificial intelligence tools such as ChatGPT when your assessment instructions say it is not permitted.

Misconduct in scholarly activity will not be tolerated and will result in consequences as outlined in [https://carleton.ca/secretariat/wp-content/uploads/Academic-Integrity-Policy-2021.pdf Carleton University’s Academic Integrity Policy]. A list of standard sanctions in the Faculty of Science can be found [https://science.carleton.ca/academic-integrity/ here].

Additional details about this process can be found on the [https://science.carleton.ca/academic-integrity/ Faculty of Science Academic Integrity website].

Students are expected to familiarize themselves with and abide by [https://carleton.ca/secretariat/wp-content/uploads/Academic-Integrity-Policy-2021.pdf Carleton University’s Academic Integrity Policy]. Claiming ignorance of or confusion about the academic integrity standards as described in the Policy does not excuse a student from responsibility for violations of those standards.

===Student Rights & Responsibilities===

Students are expected to act responsibly and engage respectfully with other students and members of the Carleton and the broader community. See the [https://carleton.ca/studentaffairs/student-rights-and-responsibilities/#sect1.1 7 Rights and Responsibilities Policy] for details regarding the expectations of non-academic behaviour of students. Those who participate with another student in the commission of an infraction of this Policy will also be held liable for their actions.

Operating Systems (Fall 2026) Course Outline

2026-09-26T16:47:11Z

Soma: /* Grading */

==Course Information==

*'''Course Number:''' COMP 3000
*'''Term:''' Fall 2026
*'''Title:''' Operating Systems
*'''Institution:''' Carleton University, School of Computer Science
*'''Instructor:''' [https://people.scs.carleton.ca/~soma Anil Somayaji] (he/him, anilsomayaji at cunet.carleton.ca): by appointment in 5137 HP and online
*'''Teaching Assistants:'''
** TAs will be announced in the first class
*'''Lectures:'''
** A: Tue. & Thu. 14:35-15:55
** B: Wed. & Fri. 8:35-9:55
*'''Tutorials:'''
** A1: Wed. 13:05-14:25
** A2: Thu. 19:35-20:55
** A3: Mon. 16:05-17:25
** B1: Mon. 14:35-15:55
** B2: Tue. 18:05-19:25
** B3: Thu. 16:05-17:25
*'''Course Website''': https://homeostasis.scs.carleton.ca/wiki/index.php/Operating_Systems_%28Fall_2026%29

For information about Carleton's academic year, including registration and withdrawal dates, see [https://calendar.carleton.ca/academicyear/ Carleton's The Academic Year].

==Course Calendar Description==

Operating system implementation course stressing fundamental issues in design and how they relate to modern computer architectures. Assignments involve the modification and extension of a multitasking operating system.

Includes: Experiential Learning Activity

Precludes additional credit for SYSC 4001. 
Prerequisites: COMP 2401 with a minimum grade of C- and COMP 2402.

==Learning Outcomes==

By the end of this course, students should:
* be able to write C code that uses low-level Linux services and should be able to implement simple Linux kernel extensions (modules),
* have a strong conceptual model of how an operating system works that allows them to determine the relative role of application and operating system code when debugging software, and
* understand the basic use and architecture of virtual machine-based cloud architectures.

Note that in order to achieve these objectives students should come into this course with a strong background in C programming and general application development.

==Topics==

Below is an approximate list of topics the course will cover. Because the concepts of operating systems are highly interconnected, many topics will be covered multiple times at increasing levels of detail. A more detailed list along with associated learning materials will be developed through the term on the [[Operating Systems (Fall 2026)|main course webpage]].

* Processes
* Computer architecture
* Filesystems
* Concurrency
* CPU Scheduling
* Virtual Memory
* Inter-Process Communication
* Networking
* High performance I/O
* Virtual Machines
* Containers
* Security
* Cloud Infrastructure

==Grading==

The marking scheme for this course is:

* 5% for lecture participation.
* 20% for tutorial participation.
* 20% for the assignments, if exam average is not too low (see below).
* 20% for the Midterm Exam, <del>Oct. 15th & 16th</del> Oct. 21st & 22nd during class.
* 35% for the Final Exam (during the final exam period).

Note the following:
* The midterm and final exams are closed book: no notes, no collaboration, no online resources, no AI. Exams will be written in an exam book based on printed exams, except where accommodations require other forms. I reserve the right to give an oral exam for deferred exams.
* The lecture and tutorial participation are fundamentally graded on a credit/no credit basis. In other words, if you show up and try you should be able to get full credit. Depending upon class performance the requirements for what is required to get full credit may change over the course of the semester; however, the expectation is that everyone who tries should be able to get 100% of these marks.
* If your assignment average is more than 25% higher than your weighted exam average (midterm & final), assignment grades are dropped and the weight assigned to the exams. For example, if you get 100% on assignments but only 70% for the exams (weighted average), the assignments would no longer count towards your final grade. (Missed exams count as a zero for grade calculation purposes.)
* Late assignments are only accepted until solutions are posted, unless extenuating circumstances apply and have been discussed with the course instructor. You have to get your tutorial marked by a TA within 8 days of the tutorial being posted, again unless extenuating circumstances apply.

I also calculate grades using alternative marking schemes at the end of the semester, assigning the highest grade for each student from any of the marking schemes. Thus your final grade may be higher than might be suggested by strict following of the above scheme.

==Communication, Lectures, and Assignments==

[[Operating Systems (Fall 2026)|The course website page listed above]] is the canonical source of information on this course. Please refer to it for updates. When significant changes are made to this document it will be either announced in lecture and/or posted in the course discussion forum.

Online course announcements and discussions will be on [https://teams.microsoft.com Microsoft Teams]. While you may discuss assignments there, do not post outright answers to them (unless the solutions have been posted). You may discuss tutorials freely, as they are graded on a participation basis. Note that solutions are never posted for tutorials.

I am best contacted via Teams direct message. I will also respond to email, preferably to my CUNET address.

Assignment and exam submissions will be through [https://brightspace.carleton.ca Brightspace]. Grades will also be posted there.

All lectures will be conducted in person except when announced otherwise, in which case they will take place over Zoom. Note that the Wednesday and Friday lectures will be repeat performances of the Tuesday and Thursday lectures, except for the first week of class when they are reversed.

Lecture recordings will be posted to the course webpage, generally within 48 hours of lecture. One or both of the lectures may be posted, depending on the week.

Lecture participation is based on interactions during lecture, such as questions asked and participation in online polls. You do not need to participate in every lecture to get full marks for this; the grade is based on the quality and quantity of your interactions. Note that grades will be calculated so that lecture participation can only improve your grade.

==Tutorials==

Tutorials are graded based on participation and effort, not correctness. They are marked out of four points. The expectation is that if you make a reasonable attempt at all parts of the tutorial, you will get 4/4 points. Thus for most students tutorials are an easy way to improve your overall grade. However, if you don't do the tutorials, you can significantly harm your grade for the course.

To get credit for tutorials, you must demonstrate to your assigned TA that you have made a reasonable attempt at the questions. This demonstration will typically be through a brief conversation where you show your TA your work, either in person or virtually. Normally this conversation should happen during your assigned tutorial time but may also take place during TA office hours. If this conversation is not feasible, at your TA's discretion you may submit written answers.

The scheduled tutorial time is a designated time when you can work with TAs and other students together, in person, on that week's tutorial. TAs will generally also be available online during these times as well, so if you aren't on campus you can still get help and get credit. You can only get credit for a tutorial within 8 days of the tutorial being made available. (Tutorials are posted generally on Sundays, so you have until the end of the following Monday to get credit.) Partial attempts may be given partial credit; however, you may improve your tutorial mark as long as it is still being accepted. Exceptions will be made only if there are extenuating circumstances.

Plan to take a 2-5 hours each week to do the assigned tutorial. The Teams tutorial channel is a forum for getting help with tutorials, potentially from other students. While you may collaborate with others and use outside resources (including AI), when asked you should indicate who helped you and and the sources you used. When submitting written answers, collaborators and sources should be clearly listed.

Your work should be your own. Please don't represent the work of others as your own, because if you do, you are subject to being reported to the Dean for plagiarism.

==Collaboration==

Collaboration on all work is allowed except for the midterm and final. Collaboration, however, should be clearly acknowledged. See below for further details.

For assignments, while you may get help from others and even collaboratively solve technical problems, the code and answers submitted should all be your own work. For example, you ''may not'' divide an assignment into parts, give a part to another student or anyone else to solve, and then submit that work as your own. You have to have participated in the creation of every part of your submitted work. An easy way to make sure this happens is never share files regarding coursework or copy and paste answers into email. Instead, meet together to work on an assignment and then separate to write up your solutions.

AIs should be treated the same as human collaborators, in that you may use them, but the answers you submit should be your own work, whether it is code or text. Note that artificially boosting your assignment grades may not be helpful if there is too much of a discrepancy between them and your exam grades (see [[#Grading|Grading]] above).

Similarity between submitted assignments and projects that has not been appropriately documented will be treated as plagiarism - the same as copying on a midterm or a final - and will be submitted to the Dean for disciplinary action.

All exams are expected to be completed individually, and without electronic aid; any communication or access of electronic devices (e.g. cellphones) during exams will be considered cheating. Use of Smart Glasses (or other similar assistive technologies) before or during a test is strictly prohibited and is considered an academic integrity violation. Even if you have prescription glasses with assistive technologies, you will not be allowed to use them during the test, so please make sure that you have acceptable prescription glasses. The proctor has the right to ask to inspect your glasses before or during the test. In addition, unless authorized with PMC accommodations, you are NOT allowed to use headphones nor ear buds during a test. Also, during a test, if you choose to wear a baseball cap, sunglasses or anything else that would prevent a proctor from monitoring where your eyes are focused during the test, you will likely be asked by a proctor to move to a different seat. Lastly, you must submit your exam before leaving the classroom or it won't be graded.

==Course Notes/Multimedia==

Video from lectures will be available via the [[Operating Systems (Fall 2026)|lecture pages on the main course website]] generally within two days after lectures are delivered. These same pages will also contain code and notes given in class.

Do not rely upon the lectures and notes to cover all material related to this class. Mastery of the tutorial material is essential for doing well on the assignments and exams. Textbook and other outside readings should be used as supplements to help you understand concepts covered in lecture and tutorial.

==Required Textbooks==

The course will be using the textbook [https://www.wiley.com/en-us/operating-system-concepts-10th-edition-p-9781119320913 Operating System Concepts, 10th Edition by Silberschatz, Galvin, & Gagne]. You should plan to read the assigned sections BEFORE class, at least briefly, so you are familiar with the context of the lecture; then, read the sections in more detail after lecture.

You may also wish to consult the free online textbook [http://pages.cs.wisc.edu/~remzi/OSTEP/ Operating Systems: Three Easy Pieces]. I used this textbook in previous runs of this class.

This course focuses much more on reading code rather than writing code. Thus, John Aycock's book, [http://pages.cpsc.ucalgary.ca/~aycock/reading-and-modifying-code.pdf Reading and Modifying Code], is worth reading to better understand how reading code differs from writing code.

==Course Software==

In this course we will be working with the [http://www.ubuntu.com/ Ubuntu] Linux distribution. You may use other Linux distributions in the tutorials to complete the assigned work; there will be differences, however, in some aspects (such as installing software), particularly if you use a distribution not based on Ubuntu or Debian.

==Undergraduate Academic Advisor==

The Undergraduate Advisors for the School of Computer Science are available in Room 5302HP; or by email at (scs.ug.advisor at cunet.carleton.ca). The undergraduate advisors can assist with information about prerequisites and preclusions, course substitutions/equivalencies, understanding your academic audit and the remaining requirements for graduation. The undergraduate advisors will also refer students to appropriate resources such as the Science Student Success Centre, Learning Support Services and Writing Tutorial Services.

==SCS Computer Laboratory==

Students taking a COMP course can access the SCS computer labs. The lab schedule and location can be found at: https://carleton.ca/scs/tech-support/computer-laboratories/. All SCS computer lab and technical support information can be found at: https://carleton.ca/scs/tech-support/. Technical support staff may be contacted in-person or virtually, see this page for details: https://carleton.ca/scs/tech-support/contact-it-support/.

==Extenuating Circumstances==

While I expect you to take this course seriously, I do not expect it to be the most important thing in your life. Physical and mental health issues, family responsibilities, natural and personal disasters, and other factors may come up over the semester. I want you to succeed in this course, and to that end I will do what I reasonably can to help you succeed. If your request can be accommodated with not unreasonable effort by me or the TAs, and the accommodation is one that is reasonable to give to anyone in your circumstances, I will do what I can.

Having said this, the main thing I have to give is extra time, but there is only so much time in a semester. Sometimes you'll need to get extra time by trying again in another semester, and that is okay. Having said that, I will always respect you enough to not pressure you to make a specific choice; you must decide what is best for your circumstances.

Remember that sometimes we all need help. [https://wellness.carleton.ca/ The Carleton Wellness Website] is a good resource if you aren't sure what to do next.

==Academic Accommodations and Regulations==

===Academic Accommodation===

Carleton is committed to providing academic accessibility for all individuals. You may need special arrangements to meet your academic obligations during the term. The accommodation request processes are outlined on the Academic Accommodations website (https://students.carleton.ca/course-outline/).

===Generative AI Usage===

As our understanding of the uses of AI and its relationship to student work and academic Integrity continue to evolve, students are required to discuss their use of AI in any circumstance not described here with the course instructor to ensure it supports the learning goals for the course.

===Academic Integrity===

Students are expected to uphold the values of academic integrity, which include fairness, honesty, trust, and responsibility. Examples of actions that compromise these values include but are not limited to plagiarism, accessing unauthorized sites for assignments or tests, unauthorized collaboration on assignments or exams, and using artificial intelligence tools such as ChatGPT when your assessment instructions say it is not permitted.

Misconduct in scholarly activity will not be tolerated and will result in consequences as outlined in [https://carleton.ca/secretariat/wp-content/uploads/Academic-Integrity-Policy-2021.pdf Carleton University’s Academic Integrity Policy]. A list of standard sanctions in the Faculty of Science can be found [https://science.carleton.ca/academic-integrity/ here].

Additional details about this process can be found on the [https://science.carleton.ca/academic-integrity/ Faculty of Science Academic Integrity website].

Students are expected to familiarize themselves with and abide by [https://carleton.ca/secretariat/wp-content/uploads/Academic-Integrity-Policy-2021.pdf Carleton University’s Academic Integrity Policy]. Claiming ignorance of or confusion about the academic integrity standards as described in the Policy does not excuse a student from responsibility for violations of those standards.

===Student Rights & Responsibilities===

Students are expected to act responsibly and engage respectfully with other students and members of the Carleton and the broader community. See the [https://carleton.ca/studentaffairs/student-rights-and-responsibilities/#sect1.1 7 Rights and Responsibilities Policy] for details regarding the expectations of non-academic behaviour of students. Those who participate with another student in the commission of an infraction of this Policy will also be held liable for their actions.

Operating Systems (Fall 2026)

2026-09-26T16:34:18Z

Soma: /* Lectures & Exams */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
'''No class ([https://www.nspw.org NSPW])''' (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] '''No class on Oct 1 ([https://www.nspw.org NSPW])'''

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 10|Midterm Review]]

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
Midterm (in class)

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems (Fall 2026)

2026-09-26T16:28:08Z

Soma: /* Lectures & Exams */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
'''No class (NSPW)''' (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]] No class on Oct 1 (NSPW)

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 10|Lecture 10]]: Midterm Review

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
Midterm (in class)

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 23|Lecture 23]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems 2026F: Assignment 1

2026-09-26T16:15:12Z

Soma:

'''This assignment is not yet finalized.'''

Please submit the answers to the following questions via Brightspace by October 5, 2026. There are 20 points in eight questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

Operating Systems (Fall 2026)

2026-09-26T16:14:41Z

Soma: /* Assignments */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] (NSPW) (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]] (NSPW)

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 10|Lecture 10]]: Midterm Review

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
Midterm (in class)

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 23|Lecture 23]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Oct. 5

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems 2026F: Assignment 1

2026-09-26T16:12:02Z

Soma:

'''This assignment is not yet finalized.'''

Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

Operating Systems 2026F: Assignment 1

2026-09-26T16:11:41Z

Soma: /* Questions */

Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

Operating Systems 2026F: Assignment 1

2026-09-26T16:11:09Z

Soma: Created page with "Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions. Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be prope..."

Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.

<li>[5] Replace line 29 in 3000menu.s (the assembly code version) with the following two lines: 
<tt>    mov $57,%eax</tt> 
<tt>    syscall</tt> 
Create a new binary by compiling the modified assembly language code, calling it 3000menu-q9. It should run the same as before.
<ol style="list-style-type:lower-alpha">
<li>[1] Is 3000menu-q9 statically or dynamically linked?</li>
</ol>
</li>
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

Operating Systems 2026F Lecture 5

2026-09-25T21:10:27Z

Soma: Created page with "==Video== Video from the lectures given on September 24th and 25th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B] ==Notes== ===Lecture 5A=== <pre> Lecture 5a ---------- The memory map of a process - every process has its own view of memory, cannot see the memory of other..."

==Video==

Video from the lectures given on September 24th and 25th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B]

==Notes==

===Lecture 5A===

<pre>
Lecture 5a
----------

The memory map of a process
- every process has its own view of memory, cannot see the memory of other processes
- what goes in that address space?

Note that, almost always, the entire address space is NOT VALID MEMORY
- if you access most of it, you'll get an error (segmentation error generally)

So what is a segment?

Well first, consider the address
- 64 bit pointer, so 2^64 possible addresses

We can't have this much RAM, so most of these addresses are invalid.
- but which ones are valid?
- and on what basis?

First, we should talk about the stack and the heap

The heap is just memory that is allocated in chunks, with each chunk pointed to
by a pointer
- when you call malloc, you're getting memory from the heap
- when you create a new object in most languages other than C, you're really
getting memory from the heap (mostly)

How to manage the heap is a complex problem, solved by memory allocators, garbage collection, etc (beyond the scope of this class)

The stack is memory that is managed in a very simple way: as a stack
- LIFO (last in, first out), e.g., a stack of plates

A stack is great because...
- no memory leaks!
- allocation and de-allocation is trivial

But the discipline of a stack only makes sense in certain contexts

Fortunately, we've built our programming languages around those contexts:
FUNCTIONS

When a program enters a function, it allocates memory for the function
When the function exits, that function's storage needs to be de-allocated

So we need somewhere to put the stack and somewhere to put the heap
- could separate, but normally are allocated together

Stack grows from himem (of data segment) down
heap grows up from the bottom of the data segment

if you put some invalid memory in the middle, you can know when they would potentially overlap (because access to it will generate an error)

a segmentation violation is just an access to memory that hasn't been allocated

So what's in memory?

<top>
command line args, environment vars

Data
------ "break"
Code

<bottom>

So the command line arguments and environment variables passed to a program
are at the top of the process's address space. The kernel put them there when
the program was launched.

fork duplicates the current process
execve replaces the current program with a new one
- neither act like normal "functions", because they are system calls

Windows has

Remember in C we make system calls by calling functions
- the functions that make system calls are using compiler-specific ways
of making the special CPU instructions for system calls

fork <- to make a process
execve <- to load a program into a process
exit <- to terminate a process
wait <- wait for a child to finish

If the parent doesn't wait for its child, and the child terminates,
the child sticks around in a zombie state
- it is already dead but still around, cannot be further killed

zombies stick around as long as their parent exists
zombies are "reaped" once the parent dies
- init or similar will call wait

How do we run programs?

Run fork
- duplicates current process, creating a child process

in the parent
- wait for the child to finish, or
- go do other work and call wait will notified
of child termination

in the child
- set up things for new program
- standard in, out, error, other open files
- close any files that SHOULD NOT be accessible
- command line arguments
- environment variables
- execve new program

In practice, you won't actually see the fork system call nowadays,
at least on Linux systems. Instead, you'll see clone

Containers - have you heard of them?

So containers are all about managing software and dependencies
- very poor security isolation properties

Turns out when you create a new process, you can change its view of the world
- e.g., give it a different view of the filesystem

namespaces is how you map the following for a process and its children

/newsystem/bin => /bin
uid 1000 => uid 0
</pre>

===Lecture 5B===

<pre>
Lecture 5b
----------

Planning to move midterm to Oct 20, 21
- so review will be Oct 15, 16
- assignment 2 will be due on the 15th 2:30 PM
- a1 will be put off a bit will finalize when posted (you'll have at least a week)
- A1 will be based on T1 and T2

For today, we're talking memory

With modern OSs, each running process gets its own address space
- so 64 bits in size
- most of that address space is not allocated, so cannot
be used or will generate an error
- typically the error is a "segmentation violation"
- so what is a segment?

A segment is a unit of memory that has a specific "purpose"
- contiguous addresses

What segments are there? You'll at least have
- code (text), read only
- data, read write
- global variables
- dynamically-allocated storage

The data segment has to store two logically distinct types of dynamically allocated memory: the stack and the heap

The heap is used to store dynamically allocated objects/data structures that have indeterminate lifetimes
- could be around for a few milliseconds
- could exist for most of the run of the program (but aren't known at compile time)
- malloc (C), new (C++), most everything in JavaScript & Python

Now this might sound complicated because IT IS
- entire area of memory management techniques
- automatic memory management is called "garbage collection"
- not only but most general approach

The heap is complex, hard to do right, so traditionally UNIX programs have avoided using the heap as much as possible and instead used the stack

So what's the stack?
- data structure that respects LIFO discipline (last in, first out)

A process normally has one stack that is used for functions
- local variables
- arguments
- return values

heap grows up from bottom of data segment
stack grows down from the top of the data segment

normally some invalid memory in the middle so you know when the two run into each other

Where do the environment variables and command line variables come from?

Those are both arguments of the execve system call

Key system calls for running a program in a new process are:
- fork
- execve
- wait

fork: duplicates the current process
- new process is called the child, old the parent
- except for the PID/PPID and the return value of fork(),
code, data, and other state are IDENTICAL

child calls execve
- sets up argv, env, open files (standard in/out/error +),
signal handlers (will discuss later)
- then loads new program binary with execve call, which REPLACES
the code in the process
- if execve returns, it failed

parent calls wait
- either literally waiting for child process to terminate, or
- in response to a signal that the child has terminated

Why does the parent care about the child process terminating?
- because it has a return status

processes terminate with the exit system call, and exit takes an integer argument that is past via wait to the parent

Modern Linux systems tend not to use the fork system call
- fork() actually calls clone

If you don't use setarch -R to run 3000memview, addresses will be randomized. This is ASLR in action: address space layout randomization
</pre>

Operating Systems 2026F: Tutorial 2

2026-09-24T21:14:40Z

Soma: /* Setting up and connecting a VM */

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in the SCS documentation. Make sure do the following:
* Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>Join the class Team if you haven't already. Link is in brightspace.</li>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F Lecture 4

2026-09-24T21:12:19Z

Soma: /* Video */

==Video==

Video from the lectures given on September 22nd and 23rd, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 Lecture 4A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 Lecture 4B]

==Notes==

===Lecture 4A===

<pre>
Lecture 4A
----------

Why is the original LinuxOnTab pretty slow?
- load the whole linux distribution over the web, all at once
- but also, it is emulating an x86 processor (32 bit)

What is happening when you load a web page? What code is running?
- by default, it is HTML, CSS, JavaScript
- so how do you run x86 code?

Sidebar - what is x86?
- refers to the instruction set of Intel (and then AMD) processors

8080 - 8 bit
8086/8088 - 16 bit
- 8088 was in the first IBM PC
80286
80386 <-- first 32 bit x86 processor
80486
Pentium
Pentium Pro
...
Intel decided to go make the Itanium for its 64 bit processor
- not backwards compatible

AMD made x86-64
- 64 bit version of x86

So what's going on in your web browser?

LinuxOnTab v1
x86 emulator
Firefox (JavaScript/WebAssembly)
x86-64 <-> Kernel

LinuxOnTab v2 (in WebAssembly)
Firefox (JavaScript/WebAssembly)
x86-64 <-> Kernel

An operating system can be big or small
- a small operating system => complexity pushed to applications
- a big operating system => applications can be simple, use rich functionality of OS

Again, files are not all "files"
- many aren't real <- /proc, /sys, /dev
- many aren't persistent <- tmpfs filesystems

Shell variables are private to a shell process

Environment variables are passed to any child processes
- a child process is created from a parent process
</pre>

===Lecture 4B===

<pre>
Lecture 4B
----------

Why are some operating systems big, and others small?
- small because you don't have room for anything else
- large because more functionality -> simpler applications
(for the developer)

Intel processors
8080 <- 8 bit
8088/8086 <- 16 bit (Original IBM PC)
80286
80386 <- 32 bit processor
80486
Pentium
Pentium Pro

Itanium <--- 64 bit processor, NOT backwards compatible

AMD came up with x86-64, and Intel had to adopt it

In LinuxOnTab, we have

LinuxOnTab v1
v86 emulator (in WebAssembly)
Browser (x86 or ARM) <-> Kernel
Hardware

LinuxOnTab v2 (in WebAssembly)
Browser (x86 or ARM) <-> Kernel
Hardware

v1 is slower because
- emulates x86-32
- loads whole disk image

v2 loads on demand and has native WebAssembly
</pre>

Operating Systems 2026F Lecture 4

2026-09-24T21:11:28Z

Soma: /* Notes */

==Video==

Video from the lectures given on September 22nd and 23rd, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 September 22nd video]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 September 23rd video]

==Notes==

===Lecture 4A===

<pre>
Lecture 4A
----------

Why is the original LinuxOnTab pretty slow?
- load the whole linux distribution over the web, all at once
- but also, it is emulating an x86 processor (32 bit)

What is happening when you load a web page? What code is running?
- by default, it is HTML, CSS, JavaScript
- so how do you run x86 code?

Sidebar - what is x86?
- refers to the instruction set of Intel (and then AMD) processors

8080 - 8 bit
8086/8088 - 16 bit
- 8088 was in the first IBM PC
80286
80386 <-- first 32 bit x86 processor
80486
Pentium
Pentium Pro
...
Intel decided to go make the Itanium for its 64 bit processor
- not backwards compatible

AMD made x86-64
- 64 bit version of x86

So what's going on in your web browser?

LinuxOnTab v1
x86 emulator
Firefox (JavaScript/WebAssembly)
x86-64 <-> Kernel

LinuxOnTab v2 (in WebAssembly)
Firefox (JavaScript/WebAssembly)
x86-64 <-> Kernel

An operating system can be big or small
- a small operating system => complexity pushed to applications
- a big operating system => applications can be simple, use rich functionality of OS

Again, files are not all "files"
- many aren't real <- /proc, /sys, /dev
- many aren't persistent <- tmpfs filesystems

Shell variables are private to a shell process

Environment variables are passed to any child processes
- a child process is created from a parent process
</pre>

===Lecture 4B===

<pre>
Lecture 4B
----------

Why are some operating systems big, and others small?
- small because you don't have room for anything else
- large because more functionality -> simpler applications
(for the developer)

Intel processors
8080 <- 8 bit
8088/8086 <- 16 bit (Original IBM PC)
80286
80386 <- 32 bit processor
80486
Pentium
Pentium Pro

Itanium <--- 64 bit processor, NOT backwards compatible

AMD came up with x86-64, and Intel had to adopt it

In LinuxOnTab, we have

LinuxOnTab v1
v86 emulator (in WebAssembly)
Browser (x86 or ARM) <-> Kernel
Hardware

LinuxOnTab v2 (in WebAssembly)
Browser (x86 or ARM) <-> Kernel
Hardware

v1 is slower because
- emulates x86-32
- loads whole disk image

v2 loads on demand and has native WebAssembly
</pre>

Operating Systems 2026F Lecture 4

2026-09-24T17:49:50Z

Soma:

Operating Systems 2026F Lecture 4

2026-09-24T17:45:29Z

Soma:

Operating Systems 2026F Lecture 4

2026-09-24T17:45:18Z

Soma: Created page with "==Video== Video from the lectures given on September 22nd and 23rd, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 September 15th video] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 September 16th video]"

Operating Systems (Fall 2026)

2026-09-21T19:16:04Z

Soma: /* Tutorials */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] (NSPW) (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]] (NSPW)

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 10|Lecture 10]]: Midterm Review

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
Midterm (in class)

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 23|Lecture 23]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Sep. 30

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems 2026F: Tutorial 2

2026-09-21T16:18:34Z

Soma:

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>Join the class Team if you haven't already. Link is in brightspace.</li>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-21T14:25:37Z

Soma: /* Setting up and connecting a VM */

'''This tutorial is not yet finalized.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>Join the class Team if you haven't already. Link is in brightspace.</li>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems (Fall 2026)

2026-09-21T13:33:27Z

Soma: /* Assignments */

==Course Outline==

[[Operating Systems (Fall 2026) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sep. 9, 10

</td>
<td>
[[Operating Systems 2026F Lecture 1|Lecture 1]]

</td>
</tr>
<tr>
<td>
Sep. 15, 16

</td>
<td>
[[Operating Systems 2026F Lecture 2|Lecture 2]]

</td>
</tr>
<tr>
<td>
Sep. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 3|Lecture 3]]

</td>
</tr>
<tr>
<td>
Sep. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 4|Lecture 4]]

</td>
</tr>
<tr>
<td>
Sep. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 5|Lecture 5]]

</td>
</tr>
<tr>
<td>
Sep. 29, 30

</td>
<td>
[[Operating Systems 2026F Lecture 6|Lecture 6]] (NSPW) (Last day to withdraw with fee adjustment: Sep. 30)

</td>
</tr>
<tr>
<td>
Oct. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 7|Lecture 7]] (NSPW)

</td>
</tr>
<tr>
<td>
Oct. 6, 7

</td>
<td>
[[Operating Systems 2026F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 9|Lecture 9]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14

</td>
<td>
[[Operating Systems 2026F Lecture 10|Lecture 10]]: Midterm Review

</td>
</tr>
<tr>
<td>
Oct. 15, 16

</td>
<td>
Midterm (in class)

</td>
</tr>
<tr>
<td>
Oct. 20, 21

</td>
<td>
[[Operating Systems 2026F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Oct. 22, 23

</td>
<td>
[[Operating Systems 2026F Lecture 12|Lecture 12]]

</td>
</tr>
<tr>
<td>
Nov. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Nov. 5, 6

</td>
<td>
[[Operating Systems 2026F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 10, 11

</td>
<td>
[[Operating Systems 2026F Lecture 15|Lecture 15]]

</td>
</tr>
<tr>
<td>
Nov. 12, 13

</td>
<td>
[[Operating Systems 2026F Lecture 16|Lecture 16]] 
(Last day to withdraw Nov. 13)

</td>
</tr>
<tr>
<td>
Nov. 17, 18

</td>
<td>
[[Operating Systems 2026F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 19, 20

</td>
<td>
[[Operating Systems 2026F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 24, 25

</td>
<td>
[[Operating Systems 2026F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Nov. 26, 27

</td>
<td>
[[Operating Systems 2026F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Dec. 1, 2

</td>
<td>
[[Operating Systems 2026F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Dec. 3, 4

</td>
<td>
[[Operating Systems 2026F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Dec. 8, 9

</td>
<td>
[[Operating Systems 2026F Lecture 23|Lecture 23]]

</td>
</tr>
<tr>
<td>
TBA

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date Available
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sep. 14

</td>
<td>
[[Operating Systems 2026F: Tutorial 1|Tutorial 1]]

</td>
</tr>
<tr>
<td>
Sep. 21

</td>
<td>
[[Operating Systems 2026F: Tutorial 2|Tutorial 2]]

</td>
</tr>
<tr>
<td>
Sep. 28

</td>
<td>
[[Operating Systems 2026F: Tutorial 3|Tutorial 3]]

</td>
</tr>
<tr>
<td>
Oct 5

</td>
<td>
[[Operating Systems 2026F: Tutorial 4|Tutorial 4]]

</td>
</tr>
<tr>
<td>
Oct. 19

</td>
<td>
[[Operating Systems 2026F: Tutorial 5|Tutorial 5]]

</td>
</tr>
<tr>
<td>
Nov. 2

</td>
<td>
[[Operating Systems 2026F: Tutorial 6|Tutorial 6]]

</td>
</tr>
<tr>
<td>
Nov. 9

</td>
<td>
[[Operating Systems 2026F: Tutorial 7|Tutorial 7]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Tutorial 8|Tutorial 8]]

</td>
</tr>
<tr>
<td>
Nov. 23

</td>
<td>
[[Operating Systems 2026F: Tutorial 9|Tutorial 9]]

</td>
</tr>
</table>

==Assignments==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Sep. 30

</td>
<td>
[[Operating Systems 2026F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 13, 14:30

</td>
<td>
[[Operating Systems 2026F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 16

</td>
<td>
[[Operating Systems 2026F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 7

</td>
<td>
[[Operating Systems 2026F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

Operating Systems 2026F: Tutorial 2

2026-09-20T15:02:38Z

Soma:

'''This tutorial is not yet finalized.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>Join the class Team if you haven't already. Link is in brightspace.</li>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:26:52Z

Soma:

'''This tutorial is not yet finalized.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:26:15Z

Soma: /* Tasks */

'''This tutorial is still in development.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language (only needed if you want to learn more):
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:23:22Z

Soma: /* C: Comparing C and assembly */

Operating Systems 2026F: Tutorial 2

2026-09-19T19:22:14Z

Soma: /* C: Comparing C and assembly */

'''This tutorial is still in development.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language:
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:22:02Z

Soma: /* C: Comparing C and assembly */

'''This tutorial is still in development.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language:
* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:20:43Z

Soma: /* B: Function calls, library calls, and system calls */

'''This tutorial is still in development.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language:
* [https://cs61.seas.harvard.edu/site/2018/Asm1/ Eddie Kohler's assembly language basics (2018)] (also see other notes from this class)
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:17:56Z

Soma: /* Connecting to Openstack */

'''This tutorial is still in development.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to [https://carleton.ca/its/vpn-access-to-campus/ VPN in] if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language:
* [https://cs61.seas.harvard.edu/site/2018/Asm1/ Eddie Kohler's assembly language basics (2018)] (also see other notes from this class)
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>

Operating Systems 2026F: Tutorial 2

2026-09-19T19:17:17Z

Soma: /* Connecting to Openstack */

'''This tutorial is still in development.'''

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Getting Started==

For this tutorial, you need to get access to a Linux or UNIX machine, and LinuxOnTab isn't enough. We strongly suggest you use an SCS Openstack instance (see below). You'll need access to a system for the entire semester, ideally the same one.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

If you find yourself searching for the answers to specific questions, you're probably doing it wrong.

Feel free to discuss this tutorial on Teams in the Tutorials channel.

'''Again, for emphasis: don't take snapshots!''' (see below)

===Connecting to Openstack===

SCS has [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ lots of documentation on openstack], including a [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/openstack-step-by-step-guide/ step-by-step guide]. Start here!

Create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

'''To access Openstack''' you must be on the Carleton network, so make sure to VPN in if you aren't on the Carleton computer or WiFi network.

'''To get added to the COMP 3000 project''', you need to [http://www.scs.carleton.ca/webacct change your SCS password] (run newacct) in order to update your account to have the right entitlements.

===Setting up and connecting a VM===

Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
* Choose the comp3000-2026f-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
* Add the ping-ssh-egress security group, and
* Associating a floating IP address.

The 192.168.X.X IP addresses are private (and cannot be accessed outside of the openstack cluster), the 134.117.X.X floating IP addresses can be accessed from the Carleton network and will allow you to access the wider Internet. You need to '''ssh to your VM instance'''. Windows, Ubuntu and MacOS all have SSH clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM (while connected to the Carleton VPN). Other tools supporting SSH (e.g., PuTTY) also work.

Once you are prompted to log in, the default user is student, default password is student. You'll have to change your password after you first login. (If you want to change your password later, use the <tt>passwd</tt> command.)

You can also connect directly to your instance with ssh -J (proxy), going through access:

ssh -J <SCS username>@access.scs.carleton.ca student@<Openstack floating IP address>

(Don't use the web console unless it is an emergency, it will be glitchy. Also, x2go won't work because the VM doesn't have a desktop environment installed, on purpose.)

===Backups===

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type:
scs-backup janedoe
and it will create a copy of everything (note: you can customize it) in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files.

You should do backups at the end of every session and before you do anything dangerous. While the cluster is generally stable, you should be ready for everything in it to be erased at a moment's notice, because it could happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed, and you'll make work for the tech staff who have to cancel what you did).'''

==Background==

A process on UNIX-like systems are separated from each other: they run in their own address space - pointers can only refer to code and data in that program, not in other programs. Because programs are separated, they can't access anything external to them without help.

Here we're going to talk about libraries and system calls, two ways programs gain access to additional functionality. Libraries are for external code that is loaded into a process, while system calls allow for code in other processes or the OS kernel to be accessed.

You may want to refer to the background from [[Operating Systems 2026F: Tutorial 1|Tutorial 1]] as well.

===Online Documentation (man pages)===

The man (short for manual) command is one of the primary ways to to access built-in software documentation. Most software packages that provide command-line programs include man pages.

For almost any commands mentioned in the tutorials, you can use <tt>man</tt> to find the usage. While you can also find documentation online for these same commands, many have multiple variants that have different functionality. The man page is guaranteed to document the version installed on your system.

Man pages are divided into multiple sections, with each section having its own purpose, e.g., 1 for general commands, 2 for system calls, and 3 for library functions. You can specify the section as the first argument to <tt>man</tt> if there is more than one man page with the same name. For instance, tee is both a command (<tt>man 1 tee</tt>) and a system call (<tt>man 2 tee</tt>). The lowest number man page will be returned if the section is not specified.

Note that the topics in man pages go beyond just software & command manuals; they also include conventions and abstract concepts (e.g., <tt>man syscalls</tt> and <tt>man man-pages</tt>). Thus if you have questions, consider browsing the man pages rather than just going to a search engine.

Note that <tt>whatis</tt> gives you a man summary, and <tt>apropos</tt> is a quick way to search man pages.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://people.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

===Assembly Language===

When we write code in C, it has to be compiled to machine code before it can be run. This compilation step doesn't happen all at once. Compilation has distinct phases:

* Compile C code into assembly code (.s files).
* Assemble assembly code into machine code placed in object code files (.o files).
* Link object code files together to create a runnable binary.

If you run <tt>gcc -v</tt>, you'll see these steps all happen in a very verbose fashion.

===Static & Dynamic Libraries===

Most applications are not self contained; they rely on lots of external code. In compiled languages such as C, external code can be brought into the process through '''linking'''. There are two basic types of linking, static and dynamic linking:
* With '''static linking''', code is brought in at compile time (specifically, in the link stage) and added to the executable. The code is now the same as other application code. (Static libraries are just collections of .o files.)
* With '''dynamic linking''', a reference to the library code is added to the binary. The actual library code has to later be loaded when the program is executed. This loading will happen before <tt>main()</tt> is called.
Static and dynamic libraries are stored in /lib and /usr/lib, traditionally.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked. If a program is statically linked <tt>ldd</tt> will have nothing to report and will generally produce an error.

Note that code in static and dynamic libraries runs inside of the process loading the code; thus, library code has the same privileges as other application code. It can do everything regular application code can do (it can access all of your code and data), but it can do no more than your code can do (it has the same restrictions on accessing system resources).

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

In general, the code you call through a system call has more privileges than regular application code. This is because a system call is a request to the operating system kernel to do something on behalf of the process, and the kernel has full privileges to the system. (Indeed, it is the part of the system that implements the process abstraction.) We're going to talk a lot about system calls this semester, this is just your introduction to the concept.

==Tasks==

===A: Exploring the Openstack VM===

<ol>
<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
<ol style="list-style-type:lower-alpha">
<li>The version of your Linux distribution and the version of your Linux kernel.</li>
<li>The name (binary path) of the current shell, and the shell version.</li>
<li>RAM, disk space, and CPU.</li>
</ol>
<li>Using the man command, find out what the following commands do: <tt>which</tt>, <tt>pwd</tt>, <tt>who</tt>, <tt>whoami</tt>, <tt>env</tt> and
<tt>whereis</tt>. Try using each of them.</li>
<li>Does the Openstack VM run the same or different programs for standard Linux commands? How do you know?</li>
<li>Making your own commands: the PATH environment variable lists the directories the shell uses to search for external commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH? Then, how to make that change permanent? Try to identify multiple ways.</li>
<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
</ol>

===B: Function calls, library calls, and system calls===

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). For example, for hello.c, you would replace all instances of "prog" in a command with "hello".

To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# Run <tt>ldd</tt> on the static and dynamic versions of the program. How does the output compare? Why?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -x '*' -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (Note: you will have to run <tt>sudo apt install ltrace</tt> to enable the command.)
# Compile the program dynamically but with "lazy" linking: <tt>gcc -O2 -z lazy prog.c -o prog-dynlazy</tt>. Run <tt>ltrace -o library-lazy.log ./prog-dynlazy</tt>. How does the output of this compare to that of the previous ltrace?
# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

===C: Comparing C and assembly===

Do the following with hello.c and syscall-hello.c, as before.

A few tips on x86-64 assembly language:
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

Resources on x86-64 assembly language:
* [https://cs61.seas.harvard.edu/site/2018/Asm1/ Eddie Kohler's assembly language basics (2018)] (also see other notes from this class)
* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

===D: Examining the runtime memory map===

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs? What happens if you run the program with the command "setarch -R ./3000memview"? (Note this changes how 3000memview is run.)
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</syntaxhighlight>

===[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]===
<syntaxhighlight lang="c" line>
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c]===
<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char *gmsg = "Global Message";

const int buffer_size = 100;

int main(int argc, char *argv[], char *envp[])
{
char *lmsg = "Local Message";
char *buf[buffer_size];
int i;

printf("Memory report\n");
printf("argv: %lx\n", (unsigned long) argv);
printf("argv[0]: %lx\n", (unsigned long) argv[0]);
printf("envp: %lx\n", (unsigned long) envp);
printf("envp[0]: %lx\n", (unsigned long) envp[0]);

printf("lmsg: %lx\n", (unsigned long) lmsg);
printf("&lmsg: %lx\n", (unsigned long) &lmsg);
printf("gmsg: %lx\n", (unsigned long) gmsg);
printf("&gmsg: %lx\n", (unsigned long) &gmsg);

printf("main: %lx\n", (unsigned long) &main);

printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));
printf("&buf: %lx\n", (unsigned long) &buf);

for (i = 0; i<buffer_size; i++) {
buf[i] = (char *) malloc(4096);
}

printf("buf[0]: %lx\n", (unsigned long) buf[0]);
printf("sbrk(0): %lx\n", (unsigned long) sbrk(0));

return 0;
}
</syntaxhighlight>

===[http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]===
<syntaxhighlight line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</syntaxhighlight>