-all processes have two interfaces: --kernel interface ---stuff relating to the Virtual Machine; memory management, threads ---generic interface for connecting to other processes (ports) --filesystem interface ---communicating with system servers/drivers ---servers/drivers create nodes in the filesystem which represent a port to the server/driver -device drivers/servers create nodes in the filesytem under /services (not a requirement, but that is where programs will look for them) -a filesystem driver creates the filesystem by creating a node for it -filesystem nodes are managed by the vfs server (Virtual File System) -processes can be either normal processes, or kernel processes --normal processes have their own address space, and can run as any user (safer, but slower, espcially for a server/driver, because all access to the server/driver requires an address space switch) --kernel processes run in the top 1 GB of RAM, and share the address space with other kenerl processes and the kernel itself. Can only be run as root for obvious reasons. (less safe, but fast, not address space switch) --programs specifiy which they can be run as (is possible to create a binary that will load as normal or kernel depending on user preference) --possibility to have some threads of a program run as kernel and others run as normal? --possibility to have a few kernel-type processes put into one big normal process? (for faster inter-device driver/server communication) -ports use messages via kernel to communicate, but ususally data structures are copied into a shared address space (previously negioated), and the messages are used to signal when it has been updated drivers for filesystems work like so: /services/ide0 - IDE driver creates this /services/part0 - Partition driver creates this, is passed /services/ide0 as an argument /services/fs0 - Filesystem driver creates this, is passed /services/part0 as an argument /bla/bla/bla/ - Mounting driver creates this, is passed /services/fs0 as an argument *** names of stuff under services is not what it will look like eventually, will be heiriarical when completed *** a nfs driver would create an fs node, being pass a server as an argument, and then the same mounting driver is used **** everything must be abstracted enough so that users and programs are presented with a POSIX/*nix like environment -/services/processs or /services/proc or something like that contains a directory for each running process, and inside each directory there is symlinks to stuff that the process will need to use, like the terminal it should print to, etc. -All processes have a small registry-like database attached to them -Can add any user-defined keys -Specifies defaults for different operations on devices (i.e., the terminal to use (stdin, stdout, etc.), the sound deviced to use) --Names are derived from the mechanism used to sort the device hierarchy -Information on priority -Information is replicated in device filesystem (perhapes is passed port its registry-like database instead of root filesystem?) -Permission on processes's node in device filesystem (owner, specificly) control the permission/owner of the process to communicate with other processes Links: -Hardware --PC Speaker ---http://courses.ece.uiuc.edu/ece291/books/labmanual/io-devices-speaker.html ---http://brand107.home.attbi.com/pc-gpe/speaker.txt