Kernel Project

From DDCIDeos
Jump to navigationJump to search

The non-distribution specific Deos Kernel project.

Description

This is a placeholder for the work performed across multiple kernel experimental and verification baselines. I.e., roadmap sorts of topics. 

Distribution   Branch
 Elbert        mainline
 FourPeaks     cachePartitioning

Perhaps this would be better handled as a "product" page like we did on the legacy wiki.

These are the current Kernel projects in work:

  • Elbert (AKA 7.10)
    • 36-bit Support (Deos RAM and FLASH still limited to 32-bit).
    • Part of Sybil
    • Thread aware debugging. (needed by torta)
  • Elbert++ (A baseline following Elbert. Unverified release ~ 8/1/2012, Verified Q2/2013)
    • E500 SPE support (kernel only, not math), (needed by malabi)
    • Complete Sybil (desired by malabi)
  • Fourpeaks-- Unverified release ~ 8/28/2012, Verified ??/2013
    • 653/WAT (torta)
  • Fourpeaks release schedule depends on Chino

Roadmap

These are the substantive changes that have been proposed for the kernel, and our current thinking of their release schedule.

  • Complete Elbert verification.
    • Merge changes into cachePartitioning and multi-core branches
  • Are there changes made by Honeywell that need to be brought forward?
  • Four peaks
    • Verification.
    • What is plan w.r.t. windows? Retain existing SCM version, or backport multi-core?
  • Multicore (on legacy wiki)
    • 2013 project numbers have been assigned.
  • Memory Pools PO imminent
  • ARM support
  • More than 32-bit Deos RAM and FLASH
  • Make HAL a separately loaded .so (to speed processor porting).

Notes from May 2013 kernel team meeting

elbert/mainline (6/1/2013)
  Finish reviews and verf work.
  M bit and L1 cache config.
  buvec kernel object pool limitation. 
  Need answer on L2 cache config and DCBF.
  Merge to cache partitioning.
  Take a look at longest criticals.
  GK and RLR part time on this until 6/1-ish
  I7 compatibility analysis


cacheParititioning (3/1/2014)
  merge in mainline changes.
  memory pools: rqts, design, tests.    Group discuss.
    - code "done" except for:
      - envelopes
      - access control (time for groups?)  Group discuss
        Proposal 1:
        - actors (process) members of users, groups
	- process member of <user1, group1, group2, ..., other)
	- objects (memory objects, file system, events, etc.)
          - file: <user1, rwx>, <group3, rwx> <other, rwx>
	  - read, write, execute
	- Names:
	  - directory services.
	    - name to handle.
	  - access control.
	    - memory pools.
	    - can write to file system
	    - can change kernel attributes
	    - Interrupt ownership ()
	    - names used to specify permission to platform resource,
	    - permitted binders (permission to create processes and memory objects)
	    - process handle specifies permissions to objects (process, semaphore, event, mailbox, mutex, memory objects)
	      - Larry, can we remove this?
	 Proposal 2:
	  - Use permitted binder like mechanism to specify access control.
	 Proposal 3:
	  - Use pool size to constrain cache interference. 
	  - IT would "shrink to fit" each memory pool quota.
	  - Desire vasCloneOverhead to be integrated into IT.
	  - Need to discuss "VAS/MOM space" + "create from parent quota" interaction that causes
	    Larry to need to create processes from system quota.
	  - writeProcessMemory() currently allocates from system quota, this causes the debugger to fail when writing to
	    "FLASH", even though there might be ram available in some other pool.
	  - Note that at this time createProcess(), createMemoryObject() and writeProcessMemory() are the only users of system quota.
	    - createProcess() and createMemoryObject() can be worked around via "create process template
	      that will never be created" hack.
	    - writeProcessMemory() may require some form of work around, such as "unshrink the memory object".
	 Proposal 4:
	  - Add a "system quota can allocate from this pool after first process dispatch" bit to each pool.
	  - new status from createProcess() "attempting to allocate system quota from system quota inhibited pool".
	  - new status from writeProcessMemory(), and createMemoryObject() "attempting to allocate system RAM from
	    system quota inhibited pool".
      - How to designate pool identifiers: names, process local pool number, ??
        Proposal 1:
	  - Define <process local pool index, ASCII name> that will end up in the process template.
	    - PD can name local pools, or have names refer to system names.
	    - AI(?) provides mapping if there are local names.
	    - Would like to be able to skip local name mapping (for simpler configurations).
	  - Multiple local indexes could refer to the same system pool. 
	    - Perhaps introduce distinct type for local pool index.
	    - Status monitor would no longer have unique inverse mapping.  Hmm.
	  - New API: "convert process local index to system pool index"
	  - System APIs will use system pool indexes.
	  - New API: "const char *convert local number to name" (optional?)
	    - Function would be in registry library.
    - Integ tool access control
    - Note: mapping kernel file sections to pools will not be in this branch/deliverable.
    - Regcheck and/or CVT
    - checksummer, not sure we handle non-contiguous DEOS_RAM properly.
    - auto created memory objects
    - More on the wikis
      - https://deos.ddci.com/ddciWiki/Deos_Cache_Partitioning
      - https://deos.ddci.com/Wiki/Kernel_Project/Memory_Pools
  rename UG/DDD to "Deos kernel..."
  complete MIPS: BIT, ELF
  porting all tests to MIPS.
    - All architecture specific #ifdefs should have else error clause.
    - What are the plans for a test team?  Bill and Ole.
    - Need a "gold standard" example test.
    - Someone triage, then telecon discuss.
  653 features:
   - Finish requirements
   - Tests implement and review
     - WAT,
     - access control on setKernelAttributesEx()
  Eliminate nested mutexes, or drop slack interaction.  Discuss with Larry.  Marketing says "huh?, sure.".  Perhaps move to multi-core.
  Eliminate checksummer?  Larry?

multi-core
  Finish scheduler
   - Is IPI to self allowed?  Affects window scheduler.
   - Is there a change to 4p raiseWindowTimer IPI to make forward compatibility easier?
  Finish x86 HAL
   - "Send IPI to specific core" to implement raiseKernelException and exceptions, note that we'll need both sync and asynch.
  PPC port
  One or more than one RMA scheduler?
  MPC2041 multi-core BSP
  qemu-ppc multi-core BSP?
  multi-core verf strategy
  POSIX/FACE something or other.
  Bounding worst case blocking time on master (and slave(s))?
  Minimize criticals, merge criticals, etc., to minimize blocking time.
  MIPS kernel dead ended?  Ask Marketing?

  
5200 port (sales prospect).

more complete support for 64-bit physical addressing.


GK & RLR do a brown bag on structural coverage tips and tricks.
  do-while
  case statements
  duplicated branches, fixed with compiler switch change -fno-re????
  what code mods were made to fix things.


ARM K61, does it have MMU?  Respond to Ole if it doesn't.

other committments:
  GK  CVTs
  RLF 653 runtime verf support.
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=Kernel_Project&oldid=11575"