User Tools

Site Tools


civilinfrastructureplatform:tsc-meetings:tsc_mm_oct212018

CIP Technical Steering Committee F2F Meeting

Date: 21 October 2018

Roll Call

TSC members

  • Attendees
    • Agustin Benito Bethencourt ( Codethink ) ( Representative )
    • Masashi Kudo (Cybertrust)
    • Nobuhiro Iwamatsu (Cybertrust) (Representative)
    • Hiroshi Mine (Hitachi)
    • Takuo Koguchi (Hitachi)
    • SZ Lin (MOXA) (Representative)
    • Masato Minda (Plat’Home) (Representative)
    • Takehisa Katayama (Renesas) (Representative) (Voting)
    • Chris Paterson (Renesas)
    • Yu Kanechika (Renesas)
    • Jan Kiszka (Siemens) ( Representative ) ( Voting )
    • Urs Gleim (Siemens)
    • Daniel Sangorrin (Toshiba)
    • Kazuhiro Hayashi (Toshiba)
    • Yoshi Kobayashi (Toshiba) (Representative) (Voting) - Chair
    • Jeff ErnstFriedman ( The Linux Foundation )

Regular TSC Meeting discussions

Agenda discussion

  • TSC meeting part 1 (9am-11:30am) Target: 20 minutes for each topic (average)
    • 1: CIP Core next (Alignment with Debian?)
    • 2: Cybersecurity standard (IEC62443)
    • 3: Test tools and Test infrastructure
    • 4. New topics discussion (what each member want to contribute to CIP?)
    • 5: Collaboration with Safety Linux Initiative (ELISA) from the Linux Foundation.
    • 6: F2F meeting dates and location around Embedded World.
  • Open TSC meeting part 2 (1:00pm-2:30pm)
  • Booth setup (3pm-6pm)
    • Board members will attend Board meeting from 3pm to 5pm (6pm at the latest).

CIP Core

Discussion: Toward the next CIP-core implementation (Kazu)

  • CIP-core contains the following works at least
    • Decide the packages which should be maintained longer term
      • Kernel
      • Core packages
    • Provide reference environment for everyone to use the maintained packages as the system
      • Hardware (Embedded boards)
      • Build system ⇒ Focus of this discussion
      • Ready-to-use images
  • Current CIP-core implementation
    • meta-debian (Deby) : Source code base approach
      • A layer for Open-Embedded Core
      • Metadata set (recipes) for cross-building Debian source packages
      • Features
        • No need to keep binaries
        • Take much time to build the images
        • High customizability
        • Various target CPUs and tuning available
    • Isar : Binary package base approach
      • Image generation tool using Debian binary packages
      • Features
        • Reuse Debian binaries and QA
        • Fast
        • Lower development costs
  • Things to do
    • Improve the current build system
      • Originally only designed for each company (TOSHIBA, Ilbers)
      • There are activities to create the collaboration tool (meta-eid)
      • Provide ready-to-use images using the build systems
  • [Current activity 1] Binary based approach: Merging the 3 projects into the one
    • EID: ELBE/Isar/Deby
  • Comparison
    • ![image alt text](img_0.png)
    • Still based on Debian binary packages
      • No enough customizability comparing the current meta-debian
      • Generated images are sometimes big for systems where H/W resources are very limited
  • [Current activity 2] Source based approach: The next generation meta-debian
    • Directions:
      • Intended to solve the issues that EID would not be able to cover
      • Should involve as many requirements in CIP members as possible
    • Current issues in meta-debian
      • Very high maintenance cost
        • Re-create over 300 recipes when base Debian version updated
      • Not fully compatible with OE-Core and BSP layers
  • Proposal
    • Focus on providing recipes for the CIP core packages (How many?)
      • ‘Rich’ environment would be provided with EID based build system
    • Move meta-debian to more Poky (OE-Core) friendly
      • Compatibility with existing Yocto resources
      • Involve Yocto users to CIP
    • Maintain as the long-term maintained Yocto
    • Development cycle
      • Develop with: The latest Debian + Poky master
      • Create the stable branch of Poky after the target Debian becomes stable
      • Only maintain the stable branch and the target Debian version
  • Discussion…
    • Is the direction better or not for CIP members who are using Yocto?
      • 1. Source code based only
      • 2. Hybrid
      • 3. Yocto friendly
      • 4. Buildstream integration tool
        • Agustin made a presentation about BuildStream:

http://www.buildstream.build

  • Is it better to only maintain Debian sources?
    • Current meta-debian approach
    • Need to maintain a part of OE-Core as well if we move to the new approach
  • Comments
  • Agustin propose a new approach “Buildstream”
  • Decision ( APPROVED ) Raised by Yoshi Kobayashi, Seconded by Urs Gelim and adopted without objection.
  • CIP Core: Having 2 profiles
    • Tiny (e.g. meta-eid (⇒ move to Debian based?), Deby-based)
    • Debian based
  • CIP member will contribute to Debian
  • Postponed
  • Integrate Yocto well

Cybersecurity standard (IEC62443)

  • Katayama-san
    • <SZ> Please notice that
      • some specific hardware components are needed for IEC-62443-4-2 (e.g., TPM), this means we do need to maintain these device drivers and applications also.
      • Secure boot is highly relevant to Arm SoC
  • Decision ( APPROVED ) Raised by Yoshi Kobayashi, Seconded by Takehisa Katayama and adopted without objection to create a CIP Security Working Group under CIP to address and make recommendations to the Technical Steering Committee as it pertains to IEC-62443-4-2 and other issues of security as defined by the TSC.

Test tools and Test infrastructure

  • (Sangorrin) Things I want to do
    • I would like to add a (ktest+Fuego+KernelCI/Squad) testing platform
    • Prepare a program that can map kernel patches to LTP tests
      • McGuire/Lukas project maps patches to configuration knobs
  • Discussion (Sangorrin): What to do about LAVA/KernelCI/AWS administration and costs?
    • We cannot access our AWS account. We need support from LF, who set it up.
    • Agustin recommended hiring a person to admin for LAB
  • Direction for this topic.
    • Make a recommendation to the governing board regarding membership in KernelCI in order to realize efficiencies regarding the LAVA testing environment. It was recommended to schedule a meeting with representatives with KernelCI. The TSC appointed Daniel Sangorrin and Chris Paterson to provide technical guidance.

Collaboration with Safety Linux Initiative (ELISA) from the Linux Foundation.

  • (Decision) Have a meeting with ELISA during OSSE

F2F meeting dates and location around Embedded World.

  • Agustin propose to LF will not happen again in 2020
  • Embedded World
    • Yoshi need to check budget…
  • (Decision) CIP TSC will consider having a F2F meeting during the Embedded World 28th of Feb.
    • Rep from Siemens will check the space within their organization at Nuremberg and Munich

Open TSC meeting discussions

  • Agustin Benito Bethencourt ( Codethink ) ( Representative )
  • Masashi Kudo (Cybertrust)
  • Nobuhiro Iwamatsu (Cybertrust) (Representative)
  • Hiroshi Mine (Hitachi)
  • Takuo Koguchi (Hitachi)
  • SZ Lin (MOXA) (Representative)
  • Masato Minda (Plat’Home) (Representative)
  • Takehisa Katayama (Renesas) (Representative) (Voting)
  • Chris Paterson (Renesas)
  • Yu Kanechika (Renesas)
  • Chris Brandt (Renesas)
  • Hung Tran (Renesas)
  • Jan Kiszka (Siemens) ( Representative ) ( Voting )
  • Urs Gleim (Siemens)
  • Daniel Sangorrin (Toshiba)
  • Kazuhiro Hayashi (Toshiba)
  • Yoshi Kobayashi (Toshiba) (Representative) (Voting) - Chair
  • Jeff ErnstFriedman ( The Linux Foundation )

New topics discussion (what each member want to contribute to CIP?)

  • Discussion (Sangorrin): do we want to do something about software updates at this stage?
    • Some update mechanism has already available
      • Swupdate+hawkbit
    • First step will be put the requirement on the table to find the gap
      • Siemens tried to find common solution. They now use swupdate and Hawkbit.
        • Eclipse IoT. 5 companies providing this combination
      • Binary delta update
      • OSTree
    • Documentation
    • Need at least an implementation for reference hardware
    • APPROVED (Decision) Create a working group to address software update mechanisms as it pertains to CIP. WIth the expectations to have a report to the board at the next f2f meeting. Urs Gleim, raised with Yoshi Kobayashi seconded. Without objection, the motion approved.
    • Daniel. S will take a role to lead
    • Expected milestones
      • Collect requirements
      • Collect use case
      • Create a reference implementation
      • Compare current options with recommendations on the preferred method(s) for CIP.

Kernel discussion

  • Proposal (Sangorrin): write a list of differences between CIP kernels and LTS kernels
    • Hardening
    • Renesas drivers
    • CIP have to explain some examples, based on accounting.
    • () Try to put information about patches wiki or other solution such as Gitlab
      • (Daniel.S) We need to keep the patches in rebase branch which is included CIP kernel only, will be merged into LTS later
      • (Ask Daniel.W) Some script to generate the data is nice to have
  • Confirm again for backporting policy
    • APPROVED (Proposal to be decided) Change “merge window” slide to not mention timeframe. Perhaps “New features may be backported as needed over time, subject to technical restrictions, with new features expected to be rare after some years.” Yoshi raised, seconded by Takehisa Katayama. Without objection, the motion was approved.
  • CIP IRC meeting
    • Motion was raised to move the IRC meeting back an hour to account for the time change in Europe.(SZ) Do we keep the same time (JP-17:00, Thursday) after November?
      • We move IrC meeting to 18:00 (JST) starting from first week of Nov.
      • The motion was raised by Yoshi Kobayashi and seconded by Agustin Benito Bethencourt. Without objection, the motion was approved.
  • Discussion (Sangorrin): how about using AI to select what non-kernel patches to backport?
    • (Jan) Interesting research topic

New Topic discussion (again)

  • Discussion (Sangorrin): do both CIP core profiles need to support the same Debian Stable (which will be LTS) version?
    • No need to sync
      • Source-based tiny (deby): Debian 8, 10…
        • In current Deby (the number of packages: over 500), it’s difficult to release for every Debian version
        • It becomes possible if Deby becomes ‘Tiny’ (assumes less than 100) + always keep development for the latest (next) Debian version in parallel
      • Binary-based: Debian 8, 9, 10…
      • Kernel: not synchronised with Debian (desire to align in future)
    • CIP intends to align with Debian as much as possible
  • License clearing for CIP related packages
    • Requests recommendations from the Linux Foundation regarding license compliance for upstream contributions
civilinfrastructureplatform/tsc-meetings/tsc_mm_oct212018.txt · Last modified: 2018/10/29 09:13 by yoshi