Date: 5 March, 2018

TSC members

In Attendance

• Jeff ErnstFriedman (The Linux Foundation)
• Yoshi Kobayashi (Toshiba) - Project Lead
• Takehisa Katayama (Renesas)
• Hidehiro Kawai (Hitachi)
• Jan Kiszka (Siemens)
• SZ Lin (MOXA)
• Chris Paterson (Renesas)
• Daniel Sangorrin (Toshiba)

• Schedule
• Consider for meetings for synergy
  • Edgex, Intel, ARM, Google. AGL..
  • Aligning LTS/LTSI/Debian kernel/AGL kernel/Android?/Ubuntu?
• Booth preparation
  • Three demos
    • Renesas: Similar RT demo as before with some improvements.
    • Siemens: IOT2040 device
    • Plat’Home: The same IoT demo as usual.
• Set-up Hours:
  • Sunday, March 11: 3:00pm – 7:00pm
  • Monday, March 12: 7:00am – 7:30am
  • All booths MUST be fully set by 7:30am Tuesday morning
• Tear-Down Hours:
  • Wednesday, March 14: 2:30pm – 5:30pm – Soft Tear-down
  • Wednesday, March 14: 5:30pm – 7:00pm – Full Tear-down
• Sponsor Registration Code?
  • Each company has two tickets.
    • 5 remaining tickets as of 3/2/2018

• Decision has been made at the previous meeting
  • CIP will not require x86 32bit mitigations
• Patches sent by Biju Das (Renesas)
  • Ben: All looks good to me. I've applied and pushed these changes.
• Q: should we add ARM64 (and its mitigations) to the scope of CIP 4.4?
  • No request from Siemens, Hitachi, Toshiba
  • Plans to add Moxa, Renesas
    • Renesas
      • Chris: we are OK postponing it until the next kernel.
    • MOXA
      • MOXA has an image that based on CIP-4.4
      • AI(MOXA): Please provide general information about your patches.
  • Jeff: both of these architectures are supported for OpenHPC.
    • AI: confirm if they will review LTS ARM64 patches for 4.4
  • Victor: we want to push our source code changes.
  • Q: How many patches need to be backported?
    • Ben needs this information to estimate how much effort is required.
    • If there are too much patches for 4.4, we may need to postpone.
    • MOXA will check
  • Q: Is there any reason why MOXA need to support ARM64 for 4.4
• Q: how should we handle the alignment of the next CIP kernel? LTS/LTSI/Debian, and.. AGL?
  • Yoshi
    • invited LTSI to CIP TSC F2F meeting.
    • Had meeting with Linaro
      • They’d asked us to join Linaro. But it is too expensive for CIP ($500K)
  • Chris: does Debian usually focus on LTS kernels already?
  • Jan: timeline for the next debian?
    • Agustin: before/during the event
      • (DebConf?)
  • Chris: CIP can probably choose our next version once we know whether Debian chooses LTS or not.
• Agustin: possible scenarios 2018 in relation with the kernel:
  • a. Increasing the scope of 4.4 maintenance.
  • b. Increase the scope of 4.4 maintenance and pick another kernel (hopefully LTS + Debian + LTSI + CIP kernel pick the same kernel version) in 2018.
  • c. Increase the scope of 4.4 maintenance, pick another kernel and start maintaining it in 2018.
• Keep for TSC F2F meeting
  • Agustin: discussions for ELC
    • Q: Who will maintain the current CIP kernel after August?
    • Q: What will CIP do to make the general alignment towards a single kernel version happen?
    • Q: Based on available manpower/resources, will we start the maintenance of a new kernel later this 2018 or we simply appoint the kernel and start later on.
  • Agustin: discussions for ELCE (ELC??)
    • If any developer involved in CIP kernel maintenance requires some training or guidance, Ben will put effort on this task while linked to CIP.
    • OSS Japan and DebConf 2018 seem the events where decisions will be taken in relation with the kernel alignment.
    • I believe though it might be wise to start pushing this explicitly asap, liked to a commitment of effort added to it, which is the best way for others to take us in consideration not just as “beneficiaries” but as “participants”.
    • I will attend to OSS Japan and I will push a request in the coming days to the Board for Ben H. to go there.
    • That alignment might open a window to keep Ben H. involved in CIP directly for that specific kernel. It is something worth exploring when the time comes. No commitments at this point though.
    • Gathering now future requirements for the next kernel is a good exercise to scope the dimension of the effort required during 2018 and 2019. Having Ben H. involved on this would be ideal, which introduces again some limitations on when should this discussion take place.
    • I see it as a good exercise to attract potential Members, specially if we discuss this in the open, which I recommend.
  • Agustin report:
    • Reviewed patches from Renesas to add support for SMP and I²C masters on R8A7743 SoC, and applied them to the CIP kernel branch
    • Reviewed Robert's merge request for B@D
    • Discussed opportunities for CIP member participation at DebConf
    • Reviewed the changes in stable release 4.4.113 (but didn't yet merge them)
• Moxa has members to maintain kernel
  • Contact to Ben by email cip-dev

• Review of CIP Core project
  • CIP Core project goals
    • CIP Core packages: This is the main goal of the CIP Core project. Maintain the most important (core) source code components (packages) during an extended period (e.g.: the lifetime of civil infrastructure systems). Check our current strategies below.
    • CIP Core reference file systems: reference file systems for reference boards provided on a best effort basis and without official support.
  • Source code maintenance strategy
    • Member backports or fixes
      • Backported patches and fixes should be sent to the Debian LTS/SLTS team for inclusion.
      • What to do while the patches are reviewed or if they are not accepted but we still want them.
        • It depends on the filesystem generation tool.
        • For deby (poky + meta-debian) we can include the patches in the corresponding recipes until they are accepted upstream.
  • Reference filesystems
    • Goal
      • To show how to create a filesystem that combines the CIP kernel and Debian LTS/SLTS source code or binary packages using various file system generation tools. The file system would target one of the CIP reference boards.
        • Not a distribution, just a reference.
        • Created on best effort by CIP members
      • Companies can customize their file systems from there (at their own risk), or just create their own file systems with their own custom scripts.
        • We do not offer any support for the reference file systems.
    • Examples
      • Deby (poky + meta-debian) based reference filesystems.
      • Filesystems based on Debian binaries: ISAR, ELBE, Debian installer, custom scripts.
      • OE/Poky-based filesystems where some recipes are modified to use the CIP kernel, or the Debian LTS/SLTS source code.

• AI(LF): infrastructure for CIP testing…??

• Shall we discuss the strategy during ELC?
  • Agustin: Ben is now tracking the patches from Y2038. They were not thinking about backporting before.
  • Yoshi: we also need to care about glibc (already part of the discussions with Debian)
  • SZ: the toolchain is also very important