c3-iocalls
Review of the effects in the kernel of systems calls for IO
Versions 20011029

--------------------------------------------------------------------------
Frist a review of some items about:
  File systems (on a disk partition):
    Inodes and Data blocks
    Directory entries (recall thes are on disk, 
  Kernel Data structures:
    Process Control Blocks PCSs (one for each user proces, in the kernel)
    File Table Entries (only one File Table in the kernel, each successful
         open results in a new FIle Table Entry)
    Vnode Table Entries (only one Vnode Table in the kernel, each open
         file on the system has exactly one Vnode Table Entry).
--------------------------------------------------------------------------   
Inodes for files: (1 per file, in a partiton with a filesystem installed)
    contents of inode:
         file type <Regular, Directory, ...>
         mode <Permissons, SUID/SGID/Sticky>
         owner uid, group gid
         dates <Creation, Modification, Access>
         link count
         file size
         disk blocks used
         ...
         pointers to data blocks
Directory entries: (directories are files, in a parittion on disk)
        ( "." , <inode nunber> )
        ( ".." , <inode nunber> )
        ( <name> , <inode nunber> )
        ...
PCB Entry; (1 for each proces, kernel data structure)
	pid, ppid
	uid, gid
	euid, egid
	umask
        ...
        file descriptors  (mask is only one bit, the "close on exec flag" )
             0       ( <mask> , <pointer to file table> )
             1       ( <mask> , <pointer to file table> )
             2       ( <mask> , <pointer to file table> )
             ...
             MAX_FD  ( <mask> , <pointer to file table> )
         (normally some of the above will be "unsed", ie NULL pointers)
File Table Entry: (only 1 File Table, kernel data structure)
       mode (from the open and a bit more informatons)
       current position
       number of links to this entry (from PCBs)
       pointer to the vnode table
Vnode Table Entry: (only 1 File Table, kernel data structure)
       device informaton
       inode number
       inode informations
          type of file
	  owner, group
	  permissions: suid, sgid, sticky bit,
	               owner rwx, group rwx, other rwx
          size
          blocks used
          pointers to data blocks
          times (change, access, modification)
          number of links from directories
          ...
       number of links to this entry (from flie node table)

----------------------------------------------------------------------------------
Consider a succesful open for a regular file as follows:
        
   open("<file path>", O_RDONLY)

What steps does the kernel go through?
   assume "<file path>" is of the form: "<path>""<file name>"
   open directory "<path>" and get the inode number that goes with "<file name>"
   if ( the inode number is already in a vnode ) {
        check the permissions in the vnode to see of the file is readable
        find the first unused fd entry in the process's PCB
        create a new file table entry
	   (the mode comes from the mode argument of the open(2) )
        set the fd entry to point at the new file table entry
        set the new file table entry pointer to point at the vnode table entry.
	   (increment the vnode table counter)
        return the new fd
   } else {
        read the inode from the disk
        check the permissions in the inode to see of the file is readable
        find the first unused fd entry in the process's PCB
        create a new file table entry
	   (the mode comes from the mode argument of the open(2) )
        set the fd entry to point at the new file table entry
        create a new vnode table entry
	   (use the inode information already read in)
        set the new file table entry pointer to point at the vnode table entry.
	   (increment the vnode table counter)
        return the new fd
   }

Note not all parts of the:
    fd entry (eg. "close on exec" flag), 
    file table entry (eg.  "number of links to this entry (from PCBs)" )
    vnode table (eg. times (change, access, modification) )
that need to be set are mentioned explicitly in the above description,
as when it says "create a new file table entry", but the settings needed
are straightforward from the definitions.

Questions:
How does this change if "file path" is a symbolic link instead of a regular file?
How does this change for a sucessful:
	open("<file path>", O_WRONLY)
	open("<file path>", O_WRONLY | O_CREAT, 0644)
	open("<file path>", O_WRONLY | O_CREAT | O_EXCL, 0644)
Ask the same type of questions about 
	close(2)
	read(2)
	write(2)
	lseek(2)
	fstat(2)
	fchmod(2)
	dup(2)
	dup2(2)
What happens to open descriptors after a successful fork() call?
What happens to open descriptors after a successful exec() call?
What happens to open descriptors when a process exit()s?