CSE 466 – Fall Introduction - 1 User / Kernel Space Physical Memory mem mapped I/O kernel code user pages user code GPLR virtual kernel C GPLR Addresses above C 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?

CSE 466 – Fall Introduction - 2 Fork – Parent and child know about each other user code virtual kernel GPLR user code virtual kernel C 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]

CSE 466 – Fall 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?

CSE 466 – Fall 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

CSE 466 – Fall 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!

CSE 466 – Fall 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)