Tasks, Memory, and Practical Issues

1
Tasks, Memory, and Practical Issues
2
File IDL bug

• The is a name space clash in file interface
• eof method collides with eof exception
• Renamed the eof exception to end_of_file
• New IDL file on web page

3
Recapping existing design

• Locating and manipulating objects
• Creating and deleting objects

4
Accessing test_client
Root Task

• resolve(root_task,
• /modules/test_client,
• root_dir_handle,
• server, handle, parts, type)
• gt
• server RO FS
• handle X
• parts 2
• type M

logs names
modulesm servicesd tasks?
Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
5
Accessing test_client
Root Task

• resolve(RO FS,
• test_client,
• X,
• server, handle, parts, type)
• gt
• server RO FS
• handle F
• parts 1
• type f

logs names
modulesm servicesd tasks?
Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
6
Accessing test_client
Root Task

• We can now use the file interface on the supplied
  object handle
• open(RO FS,
• F, file_OPEN_READ,
• file_handle)
• gt
• file_handle H
• Can now use other methods in file interface
• read/write etc.

logs names
modulesm servicesd tasks?
Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
7
The model is

• Resolve to get a handle to an object
• Provides server, handle, and type
• Access the object
• Using the type specific interface
• Specifying the object using the handle
• Method invocations should be directed at the
  given server
• Exact details of access dependent on the type

8
Some implicit assumptions made thus far

• Object handles are immutable
• Or we a susceptible to TOCTOU attacks
• Time Of Checking To Time Of Use
• When resolve completes, the server ID returned
  with the handle is the server used to invoke the
  type specific interface
• Resolve can return a different thread that
  implements the object interface

9
Making an object E.g. Service log
Root Task
names
modulesm servicesd tasks?

• Obtain handle to directory in which to create the
  object
• resolve(root_task,
• /services,
• root_dir_handle,
• server, handle, parts, type)
• gt
• server Root Task
• handle X
• parts 2
• type d

Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
10
Making an object E.g. Service log
Root Task
names logs
modulesm servicesd tasks?

• Make the new object
• mk_object(root_task,
• X, SERVICE, log)
• gt
• handle Z

Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
11
Making an object E.g. Service log
Root Task
names logs
modulesm servicesd tasks?

• Initialize the new object using type specific
  interface
• register(root_task,
• Z, logservice_thread_id)
• Now have a new service object

Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
12
mk _object model is

• Resolve the directory in which you which to
  create the object
• Mk_object of chosen type and name in that
  directory
• Initialize the object using type specific
  interface

13
Observation

• Mk_object does not return a server ID
• We currently assume that the server that resolved
  the directory implements the type specific
  interface
• E.g service interface implemented by name server
  (using inheritance)
• Implications
• all type specific interfaces must also implement
  the name interface if they support creating new
  objects
• type specific server must manage the directory
  they create objects in
• E.g file servers must manage the directories
  where files are created.
• Cant register remote objects in a central name
  server

14
Tasks within the current framework

• To create a task
• Resolve the directory in which you which to
  create the object (/tasks)
• Mk_object of chosen type and name in that
  directory (TASK, foobar)
• Initialize the object using type specific
  interface ????
• To kill a task
• Delete the object associated with the handle

15
Interface

• include "types.idl"
• typedef enum states NOT_STARTED, STARTED
  states_t
• typedef stringlt64gt cmdline_t
• const long EXISTS 1
• const long NONEXISTANT 0

16
Interface

• uuid(5)
• interface service
• exception generic_error
• exception invalid_path
• exception non_existent
• exception no_mem
• exception file_access_error

17
Interface

• void start(in handle_t task_id,
• in path_t path, in cmdline_t cmd)
• raises(invalid_path, no_mem,
  file_access_error, generic_error)
• void getcmdline(out cmdline_t cmd)
• raises (generic_error)
• void state(in handle_t task_id, out states_t
  state)
• raises(non_existent, generic_error)
• void exists_handle(in handle_t task_id, out
  long exists)
• void tid_to_handle(in server_t tid, out
  handle_t handle)
• raises(non_existent, generic_error)
• void handle_to_tid(in handle_t handle, out
  server_t tid)
• raises(non_existent, generic_error)

18
Missing Functionality

• Process model
• Hierarchy, groups, etc..
• Scheduling
• Start, stop
• Timeslice, Priority, State
• Time accounting
• Resource accounting
• VM, Phys mem, etc.
• Debugging
• Inspect, modify, monitor, etc. the contents or
  behaviour of another task

19
Making a task object
Root Task
names logs
modulesm servicesd tasks?

• Obtain handle to directory in which to create the
  object
• resolve(root_task,
• /tasks,
• root_dir_handle,
• server, handle, parts, type)
• gt
• server Root Task
• handle X
• parts 2
• type ?

Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
20
Making a task object
Root Task
names logs
modulesm servicesd tasks?

• Make the new object
• mk_object(root_task,
• X, TASK, foobar)
• gt
• handle Z

Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf
21
Making a task object
Root Task
names logs
modulesm servicesd tasks?

• Initialize the new object using type specific
  interface
• start(root_task,
• Z, /modules/test_client2,
• )
• Now have a new running task object

Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf te
st_client2
22
Implementation details

• Where is the task server thread?
• A separate thread in the root task
• Must implement naming interface and mount /tasks
  in root nameserver
• Gain parallelism
• Ideally task service is multithreaded
• Practically, if we single thread to ease
  implementation, naming can still function in
  parallel
• Practical Note Can be a client of the name
  service thread (like log service)
• The name server thread
• Include (inherit) the task interface in the name
  server thread
• Blocking the task server blocks naming
• Practical Note Task server has to use/share
  internal name resolution code.
• A separate task
• Dont do this. Currently, the only root task has
  permission to invoke task_new

23
Making an task object
Root Task
names logs taskss
modulesm servicesd tasksm

• Assume separate thread model

roott test_clientt foobart
Read-Only FS
x86-kernelf sigma0f root_taskf test_clientf te
st_client2
24
Implementation details

• What must start do
• Find the file
• Use the standard resolve protocols
• Analyze the file
• Use file interface (open, read)
• ELF? Size etc.
• Create an address space
• Initialize appropriate page table structure for
  pager.
• Load the file
• Eagerly
• On-demand
• Call task_new

25
A closer Look at the Pager Thread

• Pager receives page faults from client threads
• TID, fault address, read or write fault
• Given a TID, it need to locate the appropriate
  address space
• A TID to address-space mapping
• Given an address space and a faulting address,
  the needs to locate the appropriate page in the
  pagers address space to resolve the fault
• Need at least a page table (like VAX)
• Could augment with segment map (like SVR4)
• Once we locate page to send, we simply send
  mapping IPC
• Note we must have the page ourselves to in order
  to send it

26
To Create an address space

• Initialize a new page table (or segment map)
• Add a new mapping from tid to page table
• We new conceptually have a new empty address
  space

27
Load the file

• Eagerly
• Allocate free pages in the pagers address space
• From the frame table
• Read in appropriate parts of the file into
  appropriate pages
• Add mappings in the page table to make the page
  available in the new address space.

28
Load the file

• On-demand
• Add entries in the page table (or segment list)
  that indicate what pages are
• what parts of the file should be loaded to
  initialize this page
• Zero-fill

29
Implementation issues with loading on demand

• Care must be take to avoid deadlock locking the
  pager (entire system)
• Pager get fault
• Pager requests data from file server
• File server page faults
• Deadlock
• Pager must be multithreaded or must indirectly
  request data
• Pager must handle page fault to same page, while
  concurrent requesting that page.
• Do loading on demand only if you have lots of
  time

30
Call task_new

• We have created a representation of the new
  address space
• Page table, tid to page table mapping, etc
• Calling task_new creates a real L4 task
• New task page faults to pager
• Pager maps in pages as needed using the page table