Hi,

(2016/09/27 17:29), Agustin Benito Bethencourt wrote:

Hi,

On 22/09/16 14:59, Agustin Benito Bethencourt wrote:

Hi,

at CIP we need to have a clear view of what "Support" means in the
context of the Super Long Term Support kernel.

++ What kind of support will CIP provide? To whom?

CIP will support its members and their developers, not system
administrators or end users. With the current number of members, there
should not be a need for a 'first line' of support between them and the
CIP core developers, though that may change if membership grows
significantly.

We (our company members) agree.

Commercial Linux based distributions like RHEL promise that a subset of
the kernel module API and ABI remains stable within a major release, so
that many out-of-tree modules can be used without needing to update the
module source or binaries along with the kernel. Some IHVs rely on this
to distribute driver modules in binary form.

CIP should avoid making any such promise because:

* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not is difficult and risky - CIP
users set their own kernel configurations, so there will not be a single
kernel ABI for IHVs to target anyway

Correction:

Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that is difficult and risky - CIP users set
their own kernel configurations, so there will not be a single kernel
ABI for IHVs to target anyway

* CIP users are responsible for binary releases of both the kernel and
out-of-tree modules, so can ensure that they are properly synchronised.

* The criteria for backporting bug fixes will presumably be based on
'stable-kernel-rules.txt'. However, In CIP context, it is recommended
to be more precise than that.

We think CIP doesn't need to kepp the kernel API/ABI.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

Hi,

in preparation to start reporting about the testing efforts, I have added some content to the wiki to provide context. Please let me know if there is anything wrong or that might be improved.

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

Best Regards

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

Dear CIP friends,

At ELCE Thursday Oct 13th, the CIP group had a f2f meeting. After having lunch together, Board members met for about an hour. After that the rest of the members joined and discussed the following topics for over an hour:

++ 4.4 kernel repository

* During the event was announced that the first CIP kernel will be 4.4. At the meeting we clarified where to have the repository for that kernel.
** In the past, we reached the consensus to stay as close to the kernel community as possible. Following this approach, there is a consensus at CIP on using kernel.org as the working place for the kernel. The Linux Foundation fully supports this decision.

* The general idea is to have the working repositories where it make sense and mirror them all in a central place.

* CIP will use by default the Linux kernel tools/process to submit/review patches.
** We are currently discussing the general maintainership policies.

++ Other tools. Repositories mirrors

* As mirroring tool we will use Gitlab (as a service for now).
** As a key advantage it was stated that this tool can be set behind the firewall which for big corporations can make a difference in getting internal traction towards working in the open. Feature wise, Gitlab has what CIP needs.

* Gitlab will be use for additional required software beyond the kernel.
** When the account is set up, we will announce it.

++ CIP platforms

* The goal of the discussion was to find a common ground we all can share, assuming each member will focus most of their energy on those platforms used in production.

* CIP basic requirements for selecting a platform:
** At least one ARM and one Intel board
** At least one low cost development board for each architecture.
** No matter what CIP chooses, the list can be increased when consensus is reached.
** If any SoC joins CIP, we will obviously strongly consider adding their boards to the list.

* The boards selected at this point are:
** Beaglebone Black (TI Sitara 335x). This is a low cost board we reached consensus upon.
** Altera Cyclone V. CIP will figure out some details about how to handle off-tree code from it.

* The discussion around other boards is still ongoing.

++ Delivery (release) model

* When do we plan to release the platform? How?
** Agustin Benito Bethencourt (Codethink) will present a proposal to CIP about this to start the discussion.

++ Whitepaper

* Since CIP was announced, in April 2016, the Group has reached consensus in several fundamental topics. For this reason, we agreed to
write a Whitepaper to describe the current status and considerations of the CIP project.

* Current main consensus points are summarised in the CIP slides presented at various events. The idea is to move from there to a document.

* CIP group will start working on this topic as soon as possible.

++ 2017 CIP roadmap

* In order to define 2017 activity, CIP decided to pick up some key dates an plan milestones around them.
** Consensus was reached around ELC, LinuxCon Japan and ELCE, based on the experience from 2016.

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

Interesting to read:

https://lwn.net/Articles/705220/
(subscriptions only until next week)

In a nutshell: Folks are unhappy with the selection and review process
of patches that go into stable kernels. Various measures were proposed
like adding more tags, including "Fixes:", working more test-based,
reverting broken fixes instead of fixing up on top. The latter was the
least common denominator the community agreed upon for now.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Hi,

On 31/10/16 15:33, Agustin Benito Bethencourt wrote:

Dear CIP friends,

At ELCE Thursday Oct 13th, the CIP group had a f2f meeting. After having
lunch together, Board members met for about an hour. After that the rest
of the members joined and discussed the following topics for over an hour:

The ELCE 2016 video of the CIP talk has been published: https://www.youtube.com/watch?v=FcL2rc2o8-4&index=123&list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q

I added it to the events page of the wiki: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences

++ 4.4 kernel repository

* During the event was announced that the first CIP kernel will be 4.4.
At the meeting we clarified where to have the repository for that kernel.
** In the past, we reached the consensus to stay as close to the kernel
community as possible. Following this approach, there is a consensus at
CIP on using kernel.org as the working place for the kernel. The Linux
Foundation fully supports this decision.

* The general idea is to have the working repositories where it make
sense and mirror them all in a central place.

* CIP will use by default the Linux kernel tools/process to
submit/review patches.
** We are currently discussing the general maintainership policies.

++ Other tools. Repositories mirrors

* As mirroring tool we will use Gitlab (as a service for now).
** As a key advantage it was stated that this tool can be set behind the
firewall which for big corporations can make a difference in getting
internal traction towards working in the open. Feature wise, Gitlab has
what CIP needs.

* Gitlab will be use for additional required software beyond the kernel.
** When the account is set up, we will announce it.

++ CIP platforms

* The goal of the discussion was to find a common ground we all can
share, assuming each member will focus most of their energy on those
platforms used in production.

* CIP basic requirements for selecting a platform:
** At least one ARM and one Intel board
** At least one low cost development board for each architecture.
** No matter what CIP chooses, the list can be increased when consensus
is reached.
** If any SoC joins CIP, we will obviously strongly consider adding
their boards to the list.

* The boards selected at this point are:
** Beaglebone Black (TI Sitara 335x). This is a low cost board we
reached consensus upon.
** Altera Cyclone V. CIP will figure out some details about how to
handle off-tree code from it.

* The discussion around other boards is still ongoing.

++ Delivery (release) model

* When do we plan to release the platform? How?
** Agustin Benito Bethencourt (Codethink) will present a proposal to CIP
about this to start the discussion.

++ Whitepaper

* Since CIP was announced, in April 2016, the Group has reached
consensus in several fundamental topics. For this reason, we agreed to
write a Whitepaper to describe the current status and considerations of
the CIP project.

* Current main consensus points are summarised in the CIP slides
presented at various events. The idea is to move from there to a document.

* CIP group will start working on this topic as soon as possible.

++ 2017 CIP roadmap

* In order to define 2017 activity, CIP decided to pick up some key
dates an plan milestones around them.
** Consensus was reached around ELC, LinuxCon Japan and ELCE, based on
the experience from 2016.

Best Regards

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

Hi,

if you have any update not included in this mail, feel free to add it. I do not intend to provide a full weekly report but to inform about the activity I am aware of.

++ Meetings

* Members meeting on Monday Nov 31st

++ Kernel maintenance

* Week 44 is Plumbers week so Ben H., like many kernel hackers, are there.
* Link to CIP 4.4.27 kernel: https://git.kernel.org/cgit/linux/kernel/git/bwh/linux-cip.git

++ 4.4 LSK: evaluation of backported features

* In order to evaluate the features that has been already backported by Linaro to 4.4 kernel, that might be interested to CIP, please check the following links:
** List of backported features and other general information: https://wiki.linaro.org/LSK
** Backported features description: https://wiki.linaro.org/lsk/features
** Link to the LSK-4.4 repo: https://git.linaro.org/kernel/linux-linaro-stable.git/log/?h=linux-linaro-lsk-v4.4

++ Setting up kernelci to test CIP kernel

* No major progress this week.

++ Other topics

* A white paper is being written to develop the CIP charter. Once Members have something coherent that looks like a draft, I will publish it in the public wiki to receive your feedback.

Best Regards

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

Hi,

I am writing a description for the wiki and this topic came to my mind. It is just a detail...

I would like to propose that we say "maintenance" instead of "support" when referring to the activities we will do in the open within the CIP group.

Support has a specific meaning in the commercial world. It is referred to a "service". In order to gain traction in the industry, the confusion between maintenance and support plays against us.

In the Open Source world, both words are used indistinctly so I do not expect any issue by using only (mostly) maintenance.

So we would say Super Long Term Maintenance (SLTM).

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

Hi,

On 07/11/16 17:03, Agustin Benito Bethencourt wrote:

Hi,

if you have any update not included in this mail, feel free to add it. I
do not intend to provide a full weekly report but to inform about the
activity I am aware of.

++ Meetings

* Members meeting on Monday Nov 31st

++ Kernel maintenance

* Week 44 is Plumbers week so Ben H., like many kernel hackers, are there.
* Link to CIP 4.4.27 kernel:
https://git.kernel.org/cgit/linux/kernel/git/bwh/linux-cip.git

++ 4.4 LSK: evaluation of backported features

* In order to evaluate the features that has been already backported by
Linaro to 4.4 kernel, that might be interested to CIP, please check the
following links:
** List of backported features and other general information:
https://wiki.linaro.org/LSK
** Backported features description: https://wiki.linaro.org/lsk/features
** Link to the LSK-4.4 repo:
https://git.linaro.org/kernel/linux-linaro-stable.git/log/?h=linux-linaro-lsk-v4.4


++ Setting up kernelci to test CIP kernel

* No major progress this week.

++ Other topics

* A white paper is being written to develop the CIP charter.

Correction: the goal of the white paper is to provide an overview/status of CIP today.

Once
Members have something coherent that looks like a draft, I will publish
it in the public wiki to receive your feedback.

Best Regards

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

Hi,

I had an issue with my e-mail client. Apologies for sending the mail twice.

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

Hi,

On 08/11/16 12:08, Agustin Benito Bethencourt wrote:

Hi,

I am writing a description for the wiki and this topic came to my mind.
It is just a detail...

I would like to propose that we say "maintenance" instead of "support"
when referring to the activities we will do in the open within the CIP
group.

Support has a specific meaning in the commercial world. It is referred
to a "service". In order to gain traction in the industry, the confusion
between maintenance and support plays against us.

In the Open Source world, both words are used indistinctly so I do not
expect any issue by using only (mostly) maintenance.

So we would say Super Long Term Maintenance (SLTM).

In the past Members Meeting, last Monday, this idea was discussed. Finally the decision taken was to stick to the (S)LTS term, that is, including the word support, instead of turning it into Maintenance.

A shared argument was to follow the well known kernel nomenclature.

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

Hello
I work for consumer product and so, I join Japan Technical Jamboree
under CEWG since 4 years ago.

I feel that this is important topic.
I propagate "LTS" to my company since 4 years ago. This is also 4 years...
Hence we get better understanding.

"LTS" word use for a long time and use not only developer.
The best example is Ubuntu LTS [1]. recently, Debian project use it too[2].

I don't know when that "LTS" used. however,ubuntu lts first released on 2006.
Oh, I found the wikipedia peage[4] when this mail writing.

I think that "LTS" is not only words. it has likely culture.
Therefore, I agree to use LTS.

Thank you.
Naoki

[1] https://wiki.ubuntu.com/LTS
[2] https://wiki.debian.org/LTS
[3] https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_6.06_LTS_.28Dapper_Drake.29
[4] https://en.wikipedia.org/wiki/Long-term_support



2016-11-16 22:36 GMT+09:00 Agustin Benito Bethencourt
<agustin.benito@...>:

Hi,

one of the key parts of the maintenance work is to follow the Common Vulnerabilities and Exposures (CVE)[1] and the fixes that comes out of them, in this case, to the kernel.

We can check against CVE and commit lists from Debian[2]. Currently there is no good distribution-neutral tracker for this and MITRE is not that fast in publishing details of CVEs.

One step that Members can take is to identify the person within their organizations that deal with low level security issues and put them in contact with Ben so:
* They can provide input to Ben.
* Ben H. can explain them how a kernel in maintenance work in this regard.

A long term point for CIP Members is to get a CNA ID[3] and act as a CNA or participate through a liaison if you do not want to dedicate people to this.

[1] https://cve.mitre.org/about/faqs.html
[2] svn://scm.alioth.debian.org/svn/kernel-sec/
[3] https://cve.mitre.org/cve/cna.html

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

Hi,

as you probably know, the more features we backport, the higher will be the maintenance cost overtime so as a strategy, we need to be very conservative.

I sent a mail some days ago about the features backported already by Linaro for their LSK (Linaro Stable Kernel) for your evaluation. I bring today some potential backports related with security features and hardware support that has been identified by Ben H.

* UBSAN support:
<https://git.kernel.org/linus/c6d308534aef6c99904bf5862066360ae067abc4>

* Increased user-space ASLR range for ARM:
<https://lwn.net/Articles/667790/>

* Page poisoning on free:
<https://git.kernel.org/linus/8823b1dbc05fab1a8bec275eeae4709257c2661d>,
<https://git.kernel.org/linus/1414c7f4f7d72d138fff35f00151d15749b5beda>

* SLAB/SLUB freelist randomisation

* Hardened usercopy

* Do Members use SLUB? if not, we should take a look at KASAN support for SLAB

* drm/tilcdc update? (many bug fixes post-4.4)

* AM33xx RTC support:

<https://git.kernel.org/linus/461932dfb54ebaf7da438fd8b769a01ce97a9360>,
<https://git.kernel.org/linus/b5a553c08bec14a058501df3fa6eb39f63f00a98>


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

Hi,

++ Meetings

* This week the team at Codethink working on CIP has met f2f for the first time in Manchester, since three of us work remotely from home.
** Agreed on basic management processes we will follow.
** We have worked on the roadmap for the coming weeks.
** Moved forward the work on testing.
** You can find us in IRC channel #cip in freenode.

++ Kernel maintenance

* There is a consolidation effort of the policies that has been discussed in this mailing list in our public wiki[1]. Ben H. and myself will look into them the following days to polish them.

++ Testing

* The testing project has been created in Gitlab. A couple of colleagues at Codethink has picked up the initial effort done by Siemens and move it forward, in order to create a virtual machine with kernelci[2].
**The goal of the first milestone is that any developer with a board at her desk can test a kernel and see the results of those tests in her own machine.
** A tutorial will be published for those of you not familiar with the tools involved.

If you are interested in using kernelci in your company, please join our effort. Collaboration is working.

++ Other topics

* The CIP whitepaper keeps moving forward.

* As reported, CIP Members took as strategic decision to use the tools that for each software component, each upstream community uses. I order to consolidate our work upstream in one place, we will use Gitlab[3].
** The Gitlab instance is up and running. Feel free to join.

Best Regards

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

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

Hi,

I think it would be positive to activate the mail notifications from gitlab and send them to this list.

By activating them, you will be able to follow what is happening in our repos through mail. Using filters in your e-mail client you can manage the notification mails, so you "keep clean of notifications" this list if you need to.

I believe the traffic will not be much for now so the traffic will be affordable in a single list. We can move notifications to a new list when the activity grows.

What do you think?

Best Regards

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

Hi Agustin,

Am 28/11/2016 um 10:47 schrieb Agustin Benito Bethencourt:

I think it would be positive to activate the mail notifications from
gitlab and send them to this list.

By activating them, you will be able to follow what is happening in our
repos through mail. Using filters in your e-mail client you can manage
the notification mails, so you "keep clean of notifications" this list
if you need to.

I believe the traffic will not be much for now so the traffic will be
affordable in a single list. We can move notifications to a new list
when the activity grows.

What do you think?

That's a good idea, albeit we could also think about doing development
completely kernel-style, with a review of patches on the mailing list
(the fact that a patch has been merged or a bug has been opened is IMHO
not as interesting as what should go into the repo).

Best regards, Wolfgang

Best Regards

Hi Agustin,

What do you think?

Thanks for the suggestion. I think it is a nice idea.

Best regards,
Yoshi

On 2016/11/28 18:47, Agustin Benito Bethencourt wrote:

Hi,

I think it would be positive to activate the mail notifications from gitlab and send them to this list.
By activating them, you will be able to follow what is happening in our repos through mail. Using filters in your e-mail client you can manage the notification mails, so you "keep clean of notifications" this list if you need to.
I believe the traffic will not be much for now so the traffic will be affordable in a single list. We can move notifications to a new list when the activity grows.
What do you think?

Best Regards

On 2016-11-18 13:26, Agustin Benito Bethencourt wrote:

Hi,

as you probably know, the more features we backport, the higher will be
the maintenance cost overtime so as a strategy, we need to be very
conservative.

I sent a mail some days ago about the features backported already by
Linaro for their LSK (Linaro Stable Kernel) for your evaluation. I bring
today some potential backports related with security features and
hardware support that has been identified by Ben H.

* UBSAN support:
<https://git.kernel.org/linus/c6d308534aef6c99904bf5862066360ae067abc4>

* Increased user-space ASLR range for ARM:
<https://lwn.net/Articles/667790/>

* Page poisoning on free:
<https://git.kernel.org/linus/8823b1dbc05fab1a8bec275eeae4709257c2661d>,
<https://git.kernel.org/linus/1414c7f4f7d72d138fff35f00151d15749b5beda>

* SLAB/SLUB freelist randomisation

* Hardened usercopy

* Do Members use SLUB? if not, we should take a look at KASAN support
for SLAB

* drm/tilcdc update? (many bug fixes post-4.4)

* AM33xx RTC support:

<https://git.kernel.org/linus/461932dfb54ebaf7da438fd8b769a01ce97a9360>,
<https://git.kernel.org/linus/b5a553c08bec14a058501df3fa6eb39f63f00a98>

To add two features areas from our requirement list:

- Distributed Switch Architecture, basically the level of 4.8 would be
sufficient. However, there might be too many dependencies on
networking core changes. If we pick 4.9 as next SLTS, then this
becomes obsolete.

- Graphic support for AM57xx from more recent kernels, but things may
even still depend on TI's vendor kernel (in which case it would be
too early).

Both are a bit vague yet, but I'm trying to clarify more details.
Comments are already welcome, of course.

Jan

Hi,

On 28/11/16 14:47, Jan Kiszka wrote:

On 2016-11-18 13:26, Agustin Benito Bethencourt wrote:

Hi,

as you probably know, the more features we backport, the higher will be
the maintenance cost overtime so as a strategy, we need to be very
conservative.

I sent a mail some days ago about the features backported already by
Linaro for their LSK (Linaro Stable Kernel) for your evaluation. I bring
today some potential backports related with security features and
hardware support that has been identified by Ben H.

* UBSAN support:
<https://git.kernel.org/linus/c6d308534aef6c99904bf5862066360ae067abc4>

* Increased user-space ASLR range for ARM:
<https://lwn.net/Articles/667790/>

* Page poisoning on free:
<https://git.kernel.org/linus/8823b1dbc05fab1a8bec275eeae4709257c2661d>,
<https://git.kernel.org/linus/1414c7f4f7d72d138fff35f00151d15749b5beda>

* SLAB/SLUB freelist randomisation

* Hardened usercopy

* Do Members use SLUB? if not, we should take a look at KASAN support
for SLAB

* drm/tilcdc update? (many bug fixes post-4.4)

* AM33xx RTC support:

<https://git.kernel.org/linus/461932dfb54ebaf7da438fd8b769a01ce97a9360>,
<https://git.kernel.org/linus/b5a553c08bec14a058501df3fa6eb39f63f00a98>

To add two features areas from our requirement list:

- Distributed Switch Architecture, basically the level of 4.8 would be
sufficient. However, there might be too many dependencies on
networking core changes. If we pick 4.9 as next SLTS, then this
becomes obsolete.

- Graphic support for AM57xx from more recent kernels, but things may
even still depend on TI's vendor kernel (in which case it would be
too early).

Both are a bit vague yet, but I'm trying to clarify more details.
Comments are already welcome, of course.

This is good. It allows us to dig a little and provide some light.

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

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

Hi,

Regarding to Altera Socfpga Cyclone V, we might want to backport from 4.9;
- L2cache ECC(./arch/arm/mm/cache-l2x0.c)
- QSPI Flash controller(drivers/mtd/spi-nor/cadence-quadspi.c)

4.9 is still missing the followings which exist in the verdor tree(linux-socfpga);
- HPS2FPGA(drivers/fpga/altera-hps2fpga.c)
- NAND Flash controller(drivers/mtd/nand/denali_dt.c)
I hope we can encourage Altera to push these features upstream or do it ourselves.

Takuo