GeekFest 2014

From DDCIDeos
Jump to navigationJump to search

Description

GeekFest, our cross product line roadmapping exercise, will be held in Phoenix at DDC-I World Headquarters. The goals are to:

  1. Derive a strategy, or roadmap for the set of projects, products, and programs we will be working into the future
  2. Cross product line coordination
  3. Product line breakout sessions
  4. Process improvement discussions


Agenda

Wednesday, 29th January 2014
Time Type Topic Location Lead
09:00 - 10:00 All Hands Marketing State of Union Main Conference Room Greg Rose
10:00 - 11:00 Break-out Component: BSP Dev. Kit Bob's Office Mike Horgan
Break-out IDE: The Next Generation Main Conference Room Josh Wolfe
Break-out Kernel: MIPS/ARM Port Small Conference Room Aaron Larson
11:00 - 11:30 All Hands Discuss: IDE NextGen Main Conference Room Josh Wolfe
11:30 - 12:00 All Hands Discuss: BSP Dev. Kit Main Conference Room Mike Horgan
12:30 - 13:00 All Hands Discuss: MIPS/ARM Port Main Conference Room Aaron Larson
13:00 - 14:00 Break-out Component: File System Future Main Conference Room Mike Koye
Break-out IDE: Maintainer Use Bob's Office Josh Wolfe
Break-out Kennel: #Duplication and Distributions Small Conference Room Aaron Larson
14:00 - 14:30 All Hands Discuss: File System Future Main Conference Room Mike Koye
14:30 - 15:00 All Hands Discuss: IDE Maintainer Use Main Conference Room Josh Wolfe
15:00 - 15:30 All Hands Discuss: Duplication & Distributions Main Conference Room Aaron Larson
15:30 - 16:00 All Hands Business: LG on-site lessons learned Main Conference Room Mike Horgan
16:00 - 17:00 All Hands Business: High Level Overview Main Conference Room Bill Cronk


Thursday, 30th January 2014
Time Type Topic Location Lead
09:00 - 10:00 All Hands #Kernel: Overview of new features Main Conference Room Aaron Larson
10:00 - 11:00 Break-out Process: DO-178C Transition Bob's Office John Riedmann
Break-out IDE: Delivery/Installation Technology Improvement Main Conference Room Josh Wolfe
11:00 - 11:45 All Hands Discuss: DO-178C Transition Main Conference Room John Riedmann
11:45 - 12:30 All Hands Discuss: IDE Delivery/Installation Main Conference Room Josh Wolfe
13:00 - 14:00 Break-out Component: Device Drivers Main Conference Room Mike Horgan
Break-out IDE: Dish Bob's Office Josh Wolfe
14:00 - 14:30 All Hands Discuss: Device Drivers Main Conference Room Mike Horgan
14:30 - 15:00 All Hands Discuss: IDE Dish Main Conference Room Josh Wolfe
15:00 - 16:00 Break-out IDE: Multi-platform workstation tooling Main Conference Room Josh Wolfe
Break-out Process: Improvement Ideas Bob's Office Bill Cronk
16:00 - 16:30 All Hands Discuss: IDE Multi-platform Main Conference Room Josh Wolfe
16:30 - 17:00 All Hands Discuss: Process Improvement Ideas Main Conference Room Bill Cronk


Friday, 31st January 2014
Time Type Topic Location Lead
09:00 - 10:00 All Hands Navel gazing Main Conference Room Aaron Larson
All Hands 3x Coke Presentation Ceremony Main Conference Room Gary Kindorf
10:00 - 11:00 Break-out Component: DNT Config/CVT Tools Bob's Office Gary Kindorf
Break-out Component: DNT High DAL Embedded Main Conference Room Ryan Roffelsen
Break-out Component: DNT Workstation Tools Small Conference Room Josh Wolfe
11:00 - 11:30 All Hands Discuss: DNT Config/CVT Tools Main Conference Room Gary Kindorf
11:30 - 12:00 All Hands Discuss: DNT High DAL Embedded Main Conference Room Ryan Roffelsen
12:30 - 13:00 All Hands Discuss: DNT Workstation Tools Main Conference Room Josh Wolfe
13:00 - 17:00 TBD Flex Time: to be schedule on prior days TBD TBD


Topics

Components

  1. BSP Dev Kit; User Facing
    1. Stop "porting" platforms to the test infrastructure (esp kernel) and start having them "just work".
    2. Providing a hardware platform (or a select few) with our SW offering ready to go
  2. File System Future
  3. Device Drivers
  4. DNT: What would we like to get done for all components?

Process

  1. DO-178C Transition
  2. Improvement Ideas
    1. Automate some requirements and code checklist items via static analysis tools.
    2. Using customer IP in a bug report
    3. Switching from SVN to Git
  3. Process training, or at least review of recent problems. Audit (SOI) comments?
Breakout and Group Results
  1. Run ABC and compiler assessment earlier.
  2. Improvements to regression test suite (non-specific suggestions).
  3. Automated, nightly builds of at least mainline.
  4. Computer can help with Grammar Rule (non-qualified LLVM based tool or Regex rule?)
  5. Move formal labels.txt information to release notes (svn revision, branch). Currently one of those tuple members is duplicated between labels.txt and release notes.
  6. Procedures (How-To) should come with a checklist or be in the form of a checklist, e.g. software release how-to could contain a checklist.
  7. There was a motion to collapse test cases and procedures into a format where they are closer together (locality of reference).
  8. There was a motion to move "don't mention customer IP/business information in bug reports" from the tribal to a procedure (perhaps implemented by a computer).
  9. Write back-end documents in DocBook-to-PDF.
  10. Integration review checklist could use references rather than copies, and the engineer could refocus on performing the assessment.
  11. There was a motion to analyze the checklists for things a computer program could enforce.
  12. There was a motion to add a test procedure standard that requires an overview and "completeness" table.

IDE

Main article: OpenArbor RoadMap

  1. OpenArbor build system road map. aka DDCI_PCR:478: The Next Generation
  2. Maintainer use of OA & Better coordination between OA and Deos teams
  3. Delivery/Installation Technology Improvement
  4. Dish
  5. Multi-platform workstation tooling

Kernel

  1. MIPS/ARM Port
    1. Deos_MIPS_Port discussion. What went right? What could be done better?
    2. Deos_ARM_Port discussion.
  2. Duplication & Distributions
    1. The duplication between hypstart and the registry has become problematic with the addition of memory pools and file access controls. We need a solution that can ensure consistency between the two.
    2. What is distribution strategy fourpeaks? Separate distro?
  3. Kernel_Project Overview of new features.

Business

  1. Some sort of marketing/competitive analysis.
  2. LG on-site customer experience and lessons learned
  3. High level overview of who's doing what and what projects are coming.
  4. Navel gazing
  5. Improvement Ideas: Tools we develop that have alternatives: ABC/LDRA? MLD/GCC?

For those coming from out of town

In typical fashion we would like to conserve on travel expenses where reasonable. One way to do this is to stay at the same hotel (Best Western) and share rental cars whenever possible.

Be sure to identify yourself as an employee of DDC-I when you make your reservation and ask for the DDC-I corporate rate. That should be all you need to do. However, if they ask for it, our account number used to be: PHM-C1307.

Rideshare

First "Riders" column implies from airport to Office/Hotel (Best Western), second "Riders" column is to the airport.

My Travel Plans
Person Rental Arrival Riders Departure Riders
Aaron Larson N/A 01-27-10:14 N/A 01-31-19:45 N/A
Adina Roffelsen N/A 01-28-18:40 N/A 01-31-19:35 N/A
Bill Cronk Yes 01-28-17:50 N/A 02-03-12:35 N/A
Carlos Cespedes Yes 01-28-12:21 N/A 02-01-13:20 N/A
Gary Kindorf No 01-28-21:00 N/A 01-31-19:30 N/A
Johan O. Nielsen Yes 01-26-20:00 Thorkil 02-02-16:15 Thorkil
Karen Herrera Yes 01-28-20:29 Gary 01-31-19:40 Gary
Kelly Leonard Remote Attend 00-00-00:00 N/A 00-00-00:00 N/A
Mike Horgan Yes 01-29-08:00 N/A 01-31-13:50 N/A
Ryan Roffelsen Yes 01-27-09:30 Adina, Aaron 01-31-19:35 Adina, Aaron
Thorkil Rasmussen N/A 01-26-20:00 N/A 02-02-16:15 N/A

Entertainment

Morning Hike

6:15 am meet in the hotel parking lot. All are welcome for a hike up Piestewa Peak. Bring water and a good pair of shoes.

Marketing & Engineering Meeting on Deos Features and Enhancements

Prompted by Bob's desire for marketing and engineering to brainstorm about what desirable "extra" features or functionality could be added to Deos related to the POs we have received or will soon receive a meeting was held on this matter.

Date: December 19, 2013

Participants: Greg Rose, Gary Gilliland, Aaron Larson, Bill Cronk, Ole Oest, Ryan Roffelsen

The POs considered relevant for this discussion were

  • ARM
  • kfs capacity expansion
  • MIPS fast packet
  • FACE/653 part 2
  • Ada for Deos

In other words, when working the above, we were looking for something useful/desirable that could be added and should be added at a limited extra cost when the above work was being sone anyway.

Below is the list that was created. It is now for Marketing to set and communicate priorities to Engineering. Trace tags have been provided for easy reference. Effort estimates are:

  • Trivial: small number of days.
  • Small: small number of weeks.
  • Medium: small number of months
  • Large: large number of months.
  • Huge: You don't want to know.

Kernel, kernel file system and addressing

  • Change kernel address space/(virtual) memory layout, remove some restrictions:
    • [K1] Medium. Raise the Memory Object memory space limit (a Larry Miller wish list item)
    • [K2] Medium. Raise the current 3 GB user virtual address space limit. We could get close to 4GB
    • [K3] Small. Above 32 bit physical address support for x86. This is relatively easy to accomplish since we did it for PowerPC. However, it should be combined with moving Deos RAM and flash above 32 bit as well
    • [K4] Medium. Deos RAM or flash > 32 bit addressing (complex to do). Halfway step is possible: allow a memory pool above 32 bit, but not pool 0
  • [K5] Medium. Facilitate loading libraries from other file systems than the kfs (kernel file system)
  • [K6] Large. HAL, isolate it better so that it becomes less expensive to add sub-architectures? This isn't customer visible thus perhaps not that attractive

Cache and cache partitioning

  • [C1] Medium--Large (likely medium, but substantial uncertainty). Newer systems have more enhanced caching mechanisms than we support - we could consider a solution that gives users more flexible control over cache mechanisms. This is R&D, we're not certain that solutions exist. It would also be necessary to look out for and avoid performance overhead
  • [C2] Medium. Take L3 into account now while we're completing the current Cache Partitioning project (it was noted that Honeywell is the only customer that use processors with L3 cache)
  • [C3] Medium. Avoid cache line collisions within a partition (i.e. do cache partitioning smarter, under the auspices of the L3 work)

Multi-core

  • [M1] Large. The scheduler changes currently being designed opens several opportunities like POSIX
  • [M2] Large. Time critical tasks on more than one core. Would be a product differentiator

ARM project

  • [A1] Small-Medium (bottle filling). Add stuff (APIs) to ANSI and Math libraries in anticipation of POSIX becoming a requirement

BSP projects

  • [B1] Develop BSPs from within OA (i.e. w/o the Deos maintainer environment)

Small Footprint

  • [S1] Make application development possible w/o the network being available. This work does not align with the work associated with the PO's considered
  • [S2] Consider how else to reduce foot print (modular kernel?)

Side Notes

  • It was decided that components will continue to support all architectures rather than components be architecture specific
  • As another side note: Our current and planned baselines are not communicated to customers when we do sales presentations. This may have some advantages but also means that customers may expect that certain features are already available while they in reality are planned for a future baseline.

Duplication and Distributions

  • cd.xml vs hypfile and itconf
  • hypstart vs registry
    • Memory pool zero
    • Number of cores
    • memory map (e.g., Deos RAM and flash)
    • arcitecture (x86, ppc, etc).
  • hypstart vs cd.xml files
    • list of files
  • Cygwin, hypstart, cd.xml all know dependencies.
  • We're missing an OA and embedded architect.
    • Must understand both
  • test infrastructure needs hypstart list of files
    • Causes BSP "porting" to new platform.
    • Would be resolved by .cd.xml command line tool.
  • .options files have odd cd.xml file dependencies
    • E.g., perhaps have a dependency on "oa-dependencies" rather than inetd.

OA vs command line:

  • putapp/putall not used by OA.
  • When a command line tool is fixed, OA doesn't get the fix.

If we can't get OA to use command line tools, can we get OA to provide command line tools?

  • OA team take over desk-python-tools?

Kernel: Overview of new features

This is just a summary, Kernel_Project and linked pages have much more.

  1. 36-bit Physical Address Support
  2. Thread aware debugging.
  3. MIPS
    • MIPS fast packet.
  4. Deos_ARM_Port
  5. E500 (V1), V2, and MC
    • V1/V2 FPU (SPE) support is kernel only, not math, ansi, or 653.
  6. read/writePhysicalMemory
  7. Deos_Sybil_653_OpenArbor_Impact Sybil
    • Multiple registries in kernel file system
    • Interface to select hyperstart images
    • Access control based on ACL mechanism, no more password.
  8. WAT
    • Intervals with Fixed start and duration
    • Interesting side note: 653 runtime adds PAL requirement not in PAL SRD.
  9. Memory Pools
    • Control over memory placement, e.g.,
      • Segment of foo.exe in fast ram
      • Network buffers in off-chip memory
    • Set of ranges to allocate memory using round robin within the ranges.
      • Pool A: [block=16, num=2, offset=0], [block=16, num=2, offset=4].
      • Extension of "old style pools" to support polymorphic caches, e.g., 1M L2, 3M L3
    • Primary reason is to support Deos Cache Partitioning
    • Currently has duplication issue between hypstart and registry
    • LM talking to FAA and EASA
  10. POSIX_Access_Controls
    • Support for Cache partitioning (memory-pools is not enough by itself).
    • Migrate from names to ACL
    • Above link has overview and design.
  11. Increase kernel file limit
    • Factor of 10
    • Messes up VAS layout (probably hypstart incompatibility).
    • Considering re-laying out kernel VAS to:
      • Increase user space 3GB limit
      • Remove mom space restrictions, ref PCR:1028.
      • Large (e.g., 1-4MB page sizes)

Future

Multi-core

  1. Multiple cores with assured fixed budget
    • Execution groups, master/slave are out.
  2. Interference limited to API related objects.
    • E.g., if two cores manipulate same mutex, then they interfere, otherwise they don't
  3. Much tighter control over inter-core synchronization
    • Fine grained locking
    • Many issues remain, e.g.,
      • TLB shootdown
      • Coordinated ASIDs
      • Inter-core shared memory, e.g., perhaps no more trapless APIs.
  4. Goal is to get to wiki:Technology_readiness_level TRL 6 by EOY.
    • Customer is highly motivated.
  5. Scheduler infrastructure will support:
    • RMA
    • 653
    • POSIX
  • Multi-core ARINC 653
  • More than 32-bit Deos RAM and FLASH (speculative)

Removed features

  • Nested mutexes
  • testPageTables and testPageTablesEx
  • LLKMI (proposed)

DNT High DAL Embedded

  • Certified Network stack?
  • Certified generic PCI interface? PRL?
  • Secure sockets on lwip?
  • Port Deos to smart phone with an arm processor?
  • USB stack add E,O,U HCI (we need to do two of these)
    • Remove the drivers from the stack.
  • USB device driver
    • Network
    • Serial
    • MAL driver (memory stick)
    • Joystick/mouse
    • Audio
    • Phone touch screen
  • Graphics Driver (OpenGL)

IDE Notes

dogfood ideas:

  • Desk Examples export wizard could be the solution to distributing binary+source content to enable debugging desk tree stuff.
  • make it clearer (documention? wiki page?) how to debug regression tests.
  • dogfood future:
    • develop tests
    • run tests
    • develop level A components (using generated makefiles for RFS)
    • possibly BSP development?
  • someone needs to document how to override items on the load list
  • in general, OA's design should consider warnings rather than restrictions. (example, bsp components using the "wrong" pal.dll)

Installation Technologies:

  • isolate the TAP installer. then users could install the DDS as non-admins.
  • desk tree could be truly readonly.
  • cygwin setup.exe should hide UI
  • why can't we have spaces in some paths?
    • DDC-I can be referred to as /
    • workspace is ..
    • "external" projects and any kind of resource link can be cygwin symlinks.
    • there's also always the 8.3 dos compatibility...
  • consider an .msi installer
  • consider a monolithic installation .zip
  • consider incremental updates
    • consider web-based release publications and updates.
  • consider linux VM appliance.
  • can we offer a mintty bash shell as an alternative to the windows cmd shell.
    • don't force a change, but some developers would like it.

Porting dds to linux (and mac):

  • cygwin fork errors are currently unavoidable in windows 7.
  • desk is pretty much ready for portability.
  • installers would need to be figured out.
  • OA can be ported.
  • score ada can be ported.
  • mld on linux? port to gnat or score (and then port score).
    • gdb debugging w/ shared objects might be tricky.
    • score ada -> gdb probably doesn't speak the same dwarf.
  • business reasons?
    • targeting an appliance.
    • customers don't seem especially interested in native linux worksations.
    • maintainer efficiency.
  • cloud infrastructure?

Dreams n Talk:

  • JTAG debugging:
    • for BSP development, we might not want to compete with Lauterbach.
    • for application development, it's tricky.
      • virtual address mappings and other kernel data structures are a maintenance burdon.
      • the OA/MLD experience would be tricky to get up to speed.
    • for Target Manager stuff:
      • reimplement the Status Monitor?
      • FTP putall could probably just be reflashing a hypstart.
  • Integration Tool GUI
    • Domains:
      • kernel registry, hyperperiod diagram of budgets, processes/threads
      • 653 schedules
      • data couplings, IOI produce/consume relationships, 653 ports?
      • memory layout, cache partitioning
    • version roadmap:
      • readonly
      • click to go to source
      • edit source
    • consider looking at Honeywell's Escape tool.
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=GeekFest_2014&oldid=27097"