From: hidehiro.kawai.ez@hitachi.com (Hidehiro Kawai)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Maintenance policies and early considerations IV
Date: Thu, 27 Oct 2016 15:52:28 +0900 [thread overview]
Message-ID: <5811A42C.8020907@hitachi.com> (raw)
In-Reply-To: <57EA2E02.9020604@codethink.co.uk>
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
next prev parent reply other threads:[~2016-10-27 6:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-22 12:59 [cip-dev] Maintenance policies and early considerations IV Agustin Benito Bethencourt
2016-09-27 8:29 ` Agustin Benito Bethencourt
2016-10-07 7:34 ` 小口琢夫 / KOGUCHI,TAKUO
2016-10-07 7:54 ` Daniel Sangorrin
2016-10-10 19:05 ` Ben Hutchings
2016-10-27 6:52 ` Hidehiro Kawai [this message]
2016-10-27 5:17 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5811A42C.8020907@hitachi.com \
--to=hidehiro.kawai.ez@hitachi.com \
--cc=cip-dev@lists.cip-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.