[cgl_discussion] Re: [cgl_specs] Use case - Live patching
cherry at osdl.org
Wed Mar 30 08:50:09 PST 2005
BTW, I am moving this discussion to just cgl_discussion (not cross
posting to cgl_specs and cgl_tech_board).
On Wed, 2005-03-30 at 08:54 -0600, Corey Minyard wrote:
> Yes, I agree. The requirement should only be for user applications, not
> distro components or kernel. It should explicitly say so. However,
> Ralf said:
> Then it should be stated very explicitely that this feature may only
> be used for and by applications and that it is forbidden to patch
> the underlying distro with it.
> which would restrict the feature to forbid patching the distro components.
Just some clarification. The CGL requirements do not dictate
implementations. The CGL requirements do not restrict the usage of a
capability, they only define the core capability that must exist. The
usage models that we are developing are intended to describe how the
capability WILL be used by customers (NEPs, carriers, or end users).
The core requirement should be crisp in defining that live patching MUST
apply to user applications. This should not limit an implmentation from
also allowing live patching of distro components or the kernel. It
should not dictate a user-space only implementation.
Let's help Takashi with the actual usage cases for live patching. For
instance, can we identify some specific applications or application sets
that would benefit from live patching? We should at least be able to
call out some application types. Is 100ms for suspending an application
reasonable? How would a multi-threaded application update work? Etc.
> Brian F. G. Bidulock wrote:
> >But, as it stands, the requirement is not limited in the use case
> >to user applications (and specific ones at that). I think that not
> >forbidding expanded scope goes without saying...
> >On Wed, 30 Mar 2005, Corey Minyard wrote:
> >>No. A standard that restricts extra things a distro may do is wrong.
> >>This has nothing to do with verifiable certification.
> >>IMHO, all a distro should be required to do is allow patching of a user
> >>application. With that, it would clearly meet CGL requirements and it
> >>is verifiable. A distro may restrict that to only user applications, it
> >>may allow patching of core components, it may only allow it's own
> >>patches to be used for core components, etc. But adding a restriction
> >>where the distro may not allow it's libraries or OS to be patched is an
> >>extra restriction that adds nothing to certification and limits what a
> >>distro can to beyond the standard to compete in the marketplace.
> >>And you comment about being fuzzy about what is and is not allowed is
> >>not correct. I'm sure SuSE ships a lot of packages that are not
> >>mentioned in the CGL standard. Would you like to have to remove all
> >>those packages and only ship what is explicitly mentioned in the
> >>standard? The standard should be clear about what is required, and
> >>should not be fuzzy about that. However, it should allow things beyond
> >>the standard. Allowing this does a couple of things. It lets the
> >>distro vendor add value beyond the standard. It shows where the
> >>standard needs to be extended. And it allows new technology to be
> >>tested in the market.
> >>I believe a limitation like this would be like adding the limitation:
> >>"You can only provide support 12 hours a day." It's an unnecessary
> >>limitation. The distro should be able to provide any level of support
> >>it thinks customers require.
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
More information about the cgl_discussion