1. CSE 466 – Fall 2000 - Introduction - 1 User / Kernel Space Physical Memory mem mapped I/O kernel code user pages user code GPLR virtual kernel C0000000 GPLR Addresses above C0000000 are protected in hw. System call changes The protection bits Addresses above Cxxxxxxx are always mapped to 0xxxxxxx by VM system copy_to_user copy_from_user are not really necessary…provde some protection? Virtual Memory driver module Virtual Register user code virtual kernel GPLR IPC?

2. CSE 466 – Fall 2000 - Introduction - 2 Fork – Parent and child know about each other user code virtual kernel GPLR user code virtual kernel C0000000 GPLR Virtual Memory void main() { int pfds[2]; pipe(pfds); // create file desc. (int) if (fork()) producer(); else consumer(); } void producer() { int q = pfds[0]; while (1) {generate_data(buf); fwrite(q, buf, n); // blocking } void consumer() { int q = pfds[1]; while (1) {fread(q, buf, n); // blocking process_data(buf); }  Single Reader, Single Writer, private!  Kernel ensures mutual exclusion (Read/Write are system calls) Pid = 1Pid = 2 Duplicate! pfds[0]pfds[1]

3. CSE 466 – Fall 2000 - Introduction - 3 FIFO’s, which are named pipes  Process 1 void main() { mknod(“/tmp/myfifo”, S_IFIFO, ); // create a FIFO file node f = open(“/tmp/myfifo”, O_WRONLY); while (1) {generate_data(buf); write(f, buf, n);} }  Process 2 void main() { f = open(“/tmp/myfifo”, O_RDONLY); while (1) {read(f, buf, n); process_data(buf);} }  Works for “unrelated” processes  Multiple writers, Multiple readers  Kernel ensures mutual exclusion  Kernel does not control interleaving of writers, readers  Works fine for process that share a file system! Where is the actual queue? On the disc? In Memory?

4. CSE 466 – Fall 2000 - Introduction - 4 Implement a FIFO w/ a Device Driver  Open.. Returns a file descriptor  Read  Gets from a kernel space queue, blocks if empty  Write  Writes data into a kernel space queue, blocks if full  Close.. Releases the file descriptor

5. CSE 466 – Fall 2000 - Introduction - 5 Sockets – Networking  IPC for processes running on different machines (no shared kernel space, no shared name space)  s = socket(int domain, int type, int protocol) -- protocol is usually associated with domain but not always  domain: internet, UNIX, apple-talk…etc. How to interpret that address.  bind(int s, sockaddr *addr, n)  s is the socket identifier  sockaddr is the address (june.cs.washington.edu)  n is the length of the address  Returns a file descriptor  Now it is like a pipe, you can do read/write, send/recv, listen/connect/accept.  Several types  stream  datagram  sequential  raw  The protocol stack  mapping from application level abstractions (open, read, socket) to HW and back  Deals with inter-operability issues between different kinds of system  Could use a named pipe if have access to a shared file system!

6. CSE 466 – Fall 2000 - Introduction - 6 Stack Concept Physical layer Data-link layer Transport Physcal layer Data-link layer Transport frame packet message packet message packet Application Semantics pipe shared mem etc. pipe shared mem etc. Homework Design protocol that uses messages to implement a shared memory interface (shared variables) to processes running on separate processors Approach Think the transport layer interface to the application. Invent system calls (1) that the application should use, then determine what messages (2) need to be generated to implement the desired semantics. Be specific, give examples!! For example sockets support connect(), open(), read(), write(), close(). What do you need to implement shared variables? (1) (2)