Dear Ben Hutchings,

2017-03-09 15:33 GMT+01:00 Ben Hutchings <ben.hutchings@codethink.co.uk>:

We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?

I would really like to have IIO drivers, they are generally easy to
backport and extremely useful in industrial contexts.

Sincerely, Angelo

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

--
Profile: http://it.linkedin.com/in/compagnucciangelo

We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

Hi,

On 24/02/17 23:38, Agustin Benito Bethencourt wrote:

Hi,

during the CIP talk that Nori and I did at the Open Source Leadership
Summit on week 07, I made the following mistake:

Daniel Sangorrin, from Toshiba, has been working the last few weeks on
Fuego. I assigned to him the integration of LAVA and Fuego. The truth is
that this particular feature has been developed by Jan-Simon Möller,
from the Linux Foundation, within AGL.

I also stated that the effort is ongoing when, in fact, Jan-Simon
already completed it.

This mistake is specially inexplicable given that I am part of the AGL
CIAT group and I am closely following the progress of Fuego.

Apologies to both of you for my wrong attribution. I will change the
slides accordingly.

Slides changed.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Dear CIP friends,

as you know we released the beta version of Board at desk - Single dev on Feb 22nd a little before the CIP at ELC. It was announced through this mailing list.

That day we also communicated the first draft of the kernel maintenance policies Ben H. published on our wiki[1]. The policies are an extension from the current Linux kernel ones, having our use case in mind.

Check Yoshi's slides[2] from ELC

Christos Karamitsos has been of a great help in order to solve some technical issues during the past few weeks, working full time to help Don Brown to solve them. Thanks Christos. Robert Marshall is back in the team to focus the coming weeks in preparing the 1.0 release, substituting Christos. Welcome back again Robert.

Ben H. will be helping us in shaping the VM for his needs as kernel maintainer the coming days. He is coming to our HQ in Manchester, UK for this purpose.

Based on the feedback received after the beta release, we have added some features requests in our ticket system[3]. I will be processing them this week.

After FOSDEM, OS Leadership Summit and ELC, including the beta release, we will go back this Friday to our bi-weekly report about the technical activities related with kernel maintenance and testing.

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences
[3] https://gitlab.com/cip-project/testing/issues

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Hi,

the past few weeks, maybe related with the problems gitlab.com has experienced, the automatic update of our kernel in gitlab.com has given us problems to the extend that we took two actions:
* Disable the automatic updates
* Use directly the kernel.org repo in Board at desk - single dev

Since the week before I was at ELC and last week on vacation, the CIP kernel is not up to date compared to the kernel.org one. I am currently updating it.

I am monitoring gitlab.com service. I hope I can restore the automatic updates soon. Meanwhile, I will update it manually at least on weekly basis.

Best Regards


--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Hi,

during the CIP talk that Nori and I did at the Open Source Leadership Summit on week 07, I made the following mistake:

Daniel Sangorrin, from Toshiba, has been working the last few weeks on Fuego. I assigned to him the integration of LAVA and Fuego. The truth is that this particular feature has been developed by Jan-Simon Möller, from the Linux Foundation, within AGL.

I also stated that the effort is ongoing when, in fact, Jan-Simon already completed it.

This mistake is specially inexplicable given that I am part of the AGL CIAT group and I am closely following the progress of Fuego.

Apologies to both of you for my wrong attribution. I will change the slides accordingly.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Dear CIP friends,

The Civil Infrastructure Platform project[1], a Linux Foundation Initiative, is happy to announce the publication of a customised and easy to deploy instance of the KernelCI + LAVAv2 projects as a vagrant VM image/recipe, containing the tools and configurations used and developed by the kernelci project, the biggest collaborative testing effort.

This VM is configured so any developer can deploy it in her machine and test a specific kernel on a board physically connected to it.

Please visit the Download page[2] if you are interested in using kernelci on your own machine. To learn more about the current release please visit the feature page[3].

Goal of this effort

kernelci.org[4] is designed as a "open collaborative service", mostly used by the Linux Kernel community. At CIP, we believe this effort we now publish under beta state will help:

a.- To create a first step towards "trusted testing" within CIP for every member and the CIP kernel maintainer.

b.- To extend and simplify the current use case satisfied by kernelci.org, focusing on those embedded developers that have direct access to boards, by reducing the deployment, configuration and maintenance costs.

c.- To severely increase the number of developers and organizations willing to participate in kernelci.org by providing a simple mechanism to evaluate the technologies involved and to test Linux kernels.

The final release date will depend on the feedback received. Check the roadmap[5] for further details. CIP is a community project so we welcome contributions[6] to this effort.

Download kernelci Board @desk - Single dev[2]

[1] https://www.cip-project.org/
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage
[4] https://kernelci.org/
[5] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting#testing-at-cipactions
[6] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#participate-in-cip

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Hi,

On 20/02/17 13:16, Noriaki Fukuyasu wrote:

Hi

Please let me forward below.

I will attend to the LTSI workshop.

Regards

Nori


---------- Forwarded message ---------
From: Noriaki Fukuyasu <fukuyasu@linuxfoundation.org
<mailto:fukuyasu@linuxfoundation.org>>
Date: 2017年1月25日(水) 5:29
Subject: (Feb 21, 4pm) LTSI Workshop @ ELC Portland
To: ltsi-dev@lists.linuxfoundation.org
<mailto:ltsi-dev@lists.linuxfoundation.org>
<ltsi-dev@lists.linuxfoundation.org
<mailto:ltsi-dev@lists.linuxfoundation.org>>


Hi LTSI developers!


We are going to have another LTSI Workshop next month at ELC Portland.

If you are attending ELC, please come join!

(If you are interested in joining the workshop, please send me a note. )


Date: Feb 21st, 2017

Time: 4pm to 6pm

Venue: Director's Suite on the 3rd floor.


Agenda:

* Brief Status Update & LTSI Development Schedule
* Exchange thoughts “Upstream First” (*1). There will be 2-3 guest
speakers to talk about their experiences and thoughts on "Upstream
First" to kick the discussions.


NOTE (*1): This year, LTSI would like to spend sometime on gathering
the information of how companies are taking advantage of upstream
development. Particularly, we are interested in the following questions:

* What is the business value
* What are the challenges
* What makes it successful (from the real company experiences) etc

We are planning to write up a white paper on this subject later this
year based on the information we gather from the workshop.


See you there!!


regards


Noriaki Fukuyasu



--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@linuxfoundation.org <mailto:fukuyasu@linuxfoundation.org>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com

--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@linuxfoundation.org <mailto:fukuyasu@linuxfoundation.org>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Hi Ben,

can you provide us a status of the CIP kernel maintenance policies. I see you have been working on them

Link: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

The idea is present them during Yoshi talk on Wed Feb 22nd, right?

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

--

Hi,

please find the slides and info about the talk provided by Nori and myself at OS Leadership Summit in our wiki:

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences

Thanks Nori for sharing the talk with me.

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Hi Everyone,

I am writing to give you an update on where we stand with the Civil Infrastructure Platform (CIP).

As many of you know, we are using KernelCI for the Continuous Integration component and LAVA v2 for the kernel Testing platform. KernelCI performs the kernel builds against specific configurations and can verify boots and SOC's as well. LAVA provides the testing framework & infrastructure. Both come with complete results reporting to document what went wrong in the build, deployment or testing portion with a great level of granularity.

Where We Stand:
We have successfully merged the KernelCI VM and the LAVA Server VM into a single Virtual Machine.[1] We have KernelCI creating builds of the CIP Kernel [2] and we have LAVA running health-check tests in qemu. We are very close to having the health-check running on the Beaglebone Black, but we've had some trouble getting it communicating properly.

We expect to release the platform as a Beta version for the Embedded Linux Conference. The two original tutorials have been merged into one and can be found on the CIP Wiki.[3]


Links:

[1] CIP Testing Platform (Board-at-Desk-Single-Developer): https://gitlab.com/cip-project/board-at-desk-single-dev

[2] The CIP Kernel: https://gitlab.com/cip-project/linux-cip

[3] Tutorial: Board-at-Desk-Single-Developer KernelCI & LAVA VM Setup & Configuration: https://wiki.linuxfoundation.org/civilinfrastructureplatform/testinglavav2vmsetup


--
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown@codethink.co.uk
Mobile: +1 317-560-0513

I've just released Linux version 4.4.48-cip2. There are no new
CIP-specific changes; this just adds the fixes from stable versions
4.4.43-4.4.48 inclusive. I reviewed those fixes, but have only done
very basic manual testing of the result.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

On Tue, Jan 24, 2017 at 5:58 PM, Agustin Benito Bethencourt
<agustin.benito@codethink.co.uk> wrote:

@Arnd, is there any further documentation we should read about this topic?
What are the key activities at this point within the Linux Kernel related
with the topic? Who can we talk to related with user space? Any light you
can provide us would be helpful.

Deepa Dinamani has done some important work on the kernel, but had a hard
time getting some of the patches accepted at first. With her work, we now have
some of the basics of converting over VFS, which I assume is one of the hardest
parts.

She is also looking into refactoring my system call series now, which
is the other hard and absolutely essential part of the kernel work. Besides
those there are a couple of areas that are tricky and spread out
across the kerne
(rtc, key management, probably one more), a couple that require small interface
changes (input, v4l) and have to be done carefully, and lots of drivers that
need to be individually fixed. Once those are done, 32-bit kernels and 64-bit
kernels are equally good at dealing with y2038. I actually have an
older prototype series that removes the definition of 'time_t' inside the kernel
to ensure that there are no type confusions.

Then there are issues that affect both 32-bit and 64-bit systems and that have
to be fixed regardless. This mostly affects file systems (e.g. XFS), and many of
them won't ever get fixed (e.g. ext3 is broken, but ext4 is a working
replacement, same for NFSv2 vs NFSv3/4). The problem also exists in some
network protocols and common file formats (e.g. CPIO). Again, these have to
be dealt with individually.

In user space, Albert Aribaud has an initial glibc patch set [1], which is
most of what we require for typical 32-bit applications. glibc will
allow building
with either 32-bit or 64-bit time_t and support both at runtime
(including on old
kernels). In order to actually make it work beyond 2038, all user space has
to be recompiled against the new glibc. Once that is done, we still
have to deal with application specific bugs, where either timestamps are encoded
as 32-bit integers on-disk, or the application uses its own types
internally instead
of time_t.

Arnd

[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Civil Infrastructure Platform (CIP)
Continuous Integration of the CIP kernel using KernelCI and Testing the CIP kernel using LAVA Server v2

Hi Everyone,

I am writing to give you an update on where we stand with the Civil Infrastructure Platform (CIP).

As many of you know, we are using KernelCI for the Continuous Integration component and LAVA v2 for the kernel Testing platform. KernelCI performs the kernel builds against specific configurations and can verify boots and SOC's as well. Both come with complete results reporting to document what went wrong in the build, deployment or testing portion with a great level of granularity.

Our Focus:
We started working on this with the scenario of a "Single-Developer at their Desk with a Board" needing to build and test a kernel for a specific project. This has sharpened our focus on making it "just work," understanding that the developer does not have time to devote to the setup, configuration and maintenance of a KernelCI and LAVA server and cannot use a public service for whatever reason. However, in this day and age, we realize how desparately needed these tools are for embedded systems providers.

Where We Stand:
We currently have a KernelCI Virtual Machine running with a few sample test builds to verify that everything is working. We also have a LAVA v2 Server Virtual Machine running with a QEMU device and a Beaglebone-Black device pre-loaded. Both have a YAML health-check job loaded into their respective device types.

This setup allows a developer to compile the kernel in multiple configurations to suit the specification of their particular project and to write tests for the appropriate actions in LAVA to thouroughly prove the kernel. The tests can help fulfill and properly document any customer specifications or regulatory requirements built into the specific project.

We are approaching a beta release of the CIP Kernel along with the KernelCI & LAVA v2 Virtual Machine in Week 6 of 2017 before the Embedded Linux Conference. For the early adopters, we've provided links to the CIP-Kernel[1], the KernelCI[2] project, and the LAVA v2[3] Project. Tutorials have been created for both the KernelCI[4] and LAVA v2[5] Virtual Machines setup and configuration.

On a technical note, we are working on merging the two Virtual Machines together to ease the burden on the "Single Developer at their Desk with a Board" scenario.

Links:
[1] The CIP Kernel: https://gitlab.com/cip-project/linux-cip

[2] The KernelCI Virtual Machine files: https://gitlab.com/cip-project/kernelci-debian

[3] The LAVA v2 Virtual Machine files: https://gitlab.com/cip-project/lava2-badsd

[4] Tutorial: How to Set up and Configure a KernelCI Virtual Machine: https://wiki.linuxfoundation.org/civilinfrastructureplatform/testingkernelcivmsetup

[5] Tutorial: How to Set up and Configure a LAVA v2 Virtual Machine: https://wiki.linuxfoundation.org/civilinfrastructureplatform/testinglavav2vmsetup

Thank you!


--
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown@codethink.co.uk
Mobile: +1 317-560-0513

Hi,

during the past CIP Members meeting call, Monday 23rd January, Members agreed on bringing to the attention of CIP contributors and friends the Y2038 topic.

What is Y2038 refers to?

"Y2038 refers to an issue related to the way time is handled by computers. Time is often represented as the number of seconds since Jan 1, 1970. Whenever a 32-bit signed integer is used for this, the maximum value that can be represented is ± ~68 years, 19 days from the epoch, which corresponds to Jan 19, 2038. What happens after that is system dependent, but generally not good. A computer may act as if its time got reset to Dec 1901, or possibly to the epoch of Jan 1, 1970. It may give unexpected results or crash."

Definition extracted from http://www.y2038.com[1]. Check more about the description of the problem in Wikipedia[2].

The Linux Kernel community is already acting on this topic since version 3.17[3] at least. One of the most interesting activities is to define tasks for newbies[4] related with this topic. You can read in this article[5] an update about what is being done, from 2015 and another reference[6] from 2016.

CIP Members has expressed their interest for Y2038 on user space too.

Arnd Bergmann, in CC, is one of the advocates of the Y2038 initiative.

@Arnd, is there any further documentation we should read about this topic? What are the key activities at this point within the Linux Kernel related with the topic? Who can we talk to related with user space? Any light you can provide us would be helpful.


[1] https://y2038.com/faq/
[2] https://en.wikipedia.org/wiki/Year_2038_problem
[3] https://lwn.net/Articles/607741/
[4] https://kernelnewbies.org/y2038
[5] https://lwn.net/Articles/643234/
[6] https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-More-Y2038-Work

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

Hi Don,

On 01/23/2017 01:39 PM, Don Brown wrote:

I like the change to the patch and I'll incorporate it tonight.

Great.

We are already mirroring the KernelCI Backend and Frontend and I had
almost the exact same thought this weekend that we already need to
modify the code to get ours working. I don't mind doing this in the
short term. However, this can be a slippery slope since we could easily
get to the point where we've essentially forked their code.

I agree. There needs to be some strict rules for applying patches.

I would prefer to work with the KernelCI upstream to incorporate our
modifications into their code for the long-term.

Okay, understood. What about introducing a default configuration that
clones for upstream but it could be overwritten as config option?

Thanks,
Daniel

Hi Don,

Over the weekend I had an idea to improve it even more:


GIT_SRC="https://github.com/kernelci/kernelci-backend-config.git"
if [ -d /vagrant/kernelci-backend-config ]; then
GIT_SRC=/vagrant/kernelci-backend-config
fi
git clone $GIT_SRC kernelci-backend


If there is a repo available on /vagrant we clone from it. I
think it would be even better just to copy the working
directory instead of cloning. That would allow to hack on the
files without committing all the time.

So this would change to:

if [ -d /vagrant/kernelci-backend-config ]; then
cp -r /vagrant/kernelci-backend-config kernelci-backend
else
git clone https://github.com/kernelci/kernelci-backend-config.git kernelci-backend
fi

What do you think about this?

And another idea I had: we should create a mirror of kernelci sources
clone from the mirror. I am pretty sure soon we have some patches
which need to be around to get our setup running which aren't
available in the upstream repository. For example I had to do this here:


--- a/roles/install-deps/tasks/install-mongodb.yml
+++ b/roles/install-deps/tasks/install-mongodb.yml
@@ -2,7 +2,7 @@

- name: Add MongoDB apt key (Ubuntu)
apt_key: id=7F0CEB10
- keyserver=hkp://keyserver.ubuntu.com
+ keyserver=hkp://keyserver.ubuntu.com:80
when: ansible_lsb.id == "Ubuntu"
tags:
- install
@@ -11,7 +11,7 @@

- name: Add MongoDB apt key (Debian)
apt_key: id=EA312927
- keyserver=hkp://keyserver.ubuntu.com
+ keyserver=hkp://keyserver.ubuntu.com:80
when: ansible_lsb.id == "Debian"
tags:
- install

Thanks,
Daniel