NFU Specification: Difference between revisions

From ReddNet
Jump to navigation Jump to search
No edit summary
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
Simple overview:
Simple overview:
* NFU server -- "adjacent" to IBP depot, runs NFU Ops
* Three components:
* NFU Op -- lightweight program, written in C, or Java, depending on server.
** NFU server -- "adjacent" to IBP depot, runs NFU Ops
* NFU client -- initiates launch of an nfuOp and exchanges data with it.
** NFU Op -- lightweight program, written in C, or Java, depending on server.
* NFU API:
** NFU client -- initiates launch of an nfu Op and exchanges data with it.
** Two types of data exchange:
* NFU API -- Two iotypes categories for data exchange between nfu_op and nfu_client:
** 1. variable exchange
** IBP_VAL_[IN, OUT, INOUT]
***IBP_VAL_[IN, OUT, INOUT]
*** variable/values exchanged directly between nfu client and nfu Op
*** variable/values exchanged directly between nfu client and nfu Op
** 2. IBP Cap handling
** IBP_REF_[RD, WR, RDWR]
*** NFU Server (not nfuOp) processes IBP Caps
*** NFU Server (not nfuOp) processes IBP Caps
***IBP_REF_[RD, WR, RDWR]
***E.G. _RD: client sends readCap to server, NFU server provides nfuOp a pointer to mmap of the allocation
***E.G. _RD: client sends readCap to server, NFU server provides nfuOp a pointer to mmap of the allocation
***nfuOp does not receive readCap string
***nfuOp does not receive readCap string
Line 16: Line 14:
** Java NFU server has VM isolation of nfuOp
** Java NFU server has VM isolation of nfuOp
** UTK NFU server has option to run Cap as process to isolate nfuOp from server
** UTK NFU server has option to run Cap as process to isolate nfuOp from server
** UTK NFU server mmaps allocations from readCaps, i.e. nfuOp has no direct knowledge of allocation file names.
* compatibility issues:
* compatibility issues:
** Java NFU server currently has no way to run C nfuOps
** Java NFU server currently has no way to run C nfu Ops
** if nfu server is not part of the ibp depot, then all IBP_REF_* exchanges need to be changed to IBP_VAL_* exchanges forcing the nfuOp to process IBP caps.
** if nfu server is not part of the ibp depot, then all IBP_REF_* exchanges need to be changed to IBP_VAL_* exchanges  
*** this disables 1/2 of the NFU api
*** this forces the nfuOp to process IBP caps which would otherwise be processed by the nfuServer.
*** this disables 1/2 of the NFU iotypes

Latest revision as of 09:02, 2 July 2008

Simple overview:

  • Three components:
    • NFU server -- "adjacent" to IBP depot, runs NFU Ops
    • NFU Op -- lightweight program, written in C, or Java, depending on server.
    • NFU client -- initiates launch of an nfu Op and exchanges data with it.
  • NFU API -- Two iotypes categories for data exchange between nfu_op and nfu_client:
    • IBP_VAL_[IN, OUT, INOUT]
      • variable/values exchanged directly between nfu client and nfu Op
    • IBP_REF_[RD, WR, RDWR]
      • NFU Server (not nfuOp) processes IBP Caps
      • E.G. _RD: client sends readCap to server, NFU server provides nfuOp a pointer to mmap of the allocation
      • nfuOp does not receive readCap string
  • security issues
    • Java NFU server has VM isolation of nfuOp
    • UTK NFU server has option to run Cap as process to isolate nfuOp from server
    • UTK NFU server mmaps allocations from readCaps, i.e. nfuOp has no direct knowledge of allocation file names.
  • compatibility issues:
    • Java NFU server currently has no way to run C nfu Ops
    • if nfu server is not part of the ibp depot, then all IBP_REF_* exchanges need to be changed to IBP_VAL_* exchanges
      • this forces the nfuOp to process IBP caps which would otherwise be processed by the nfuServer.
      • this disables 1/2 of the NFU iotypes
Retrieved from "http://www.reddnet.org/mwiki/index.php?title=NFU_Specification&oldid=3581"