I've had a few potential clients ask how security updates and general patches are applied to embedded products built using Yocto.

If they're really embedded, then the only way to to this is by replacing the rootfs - especially when they boot read-only.

A second complication is when support for a BSP gets dropped so later versions, which generally include updates and patches, can't be used.

It feels to me as if there should be some "LTS" releases which developers could focus on when choosing a version.

Or is there already some way of doing this that I just haven't spotted?

Chris Tapp

opensource@...
www.keylevel.com

On 5/8/14, 2:54 PM, Chris Tapp wrote:

I've had a few potential clients ask how security updates and general patches
are applied to embedded products built using Yocto.

The Yocto Project, via it's contributors usually provides support for the -two- releases + master.

That means effectively a one year community (best-effort) support model for each release. So today that would be 1.5 and 1.6. (Master is continuously developed, and I'd expect any relevant fixes to go there as well.)

Note, this is all contingent upon contributions from Yocto Project members and the Open Embedded community at large. Without contributions, there is no support.

If they're really embedded, then the only way to to this is by replacing the
rootfs - especially when they boot read-only.

See the million threads on "field upgrade". There is no one answer. Device upgrade, Image upgrade, package upgrade, and file upgrades are all possibilities... but these need to be built into the device during it's design. There are no best practices available, as everyone seems to have different requirements.

A second complication is when support for a BSP gets dropped so later
versions, which generally include updates and patches, can't be used.

If you are releasing a product, you shouldn't be expecting to migrate (in a product lifecycle) from YP 1.4 to YP 1.5 to YP 1.6, etc. Each release is individual, and an overall target based upgrade and BSP obsolescence is not part of the project. This is really the realm of the device manufacturer, OSV and other commercial vendors of YP components.

It feels to me as if there should be some "LTS" releases which developers
could focus on when choosing a version.

It all comes down to contributions in the end. If nobody is contributing, don't expect updates. There has been talk over time of an LTS type release. I've heard everything from extending the 1 year to '2' years.. or as contributions are available.

But if you want long term support, your best bet is to find an OSV (or other Yocto Project participant) that is willing to do long term support and maintenance of a product.

(Speaking for Wind River for a second, we do offer extended support for many many more years then what I would ever expect the community to support. I would expect the same from our competitors.)

Or is there already some way of doing this that I just haven't spotted?

This is where community support really transitions to commercial. The community is interested in enabling new designs and 'maker' projects. Commercial is interested in building products and long term support. (IMHO, others might disagree.)

--Mark

Chris Tapp

opensource@...
www.keylevel.com

Hi Mark,

Thanks for the comments.

On 8 May 2014, at 21:11, Mark Hatle <mark.hatle@...> wrote:

On 5/8/14, 2:54 PM, Chris Tapp wrote:

I've had a few potential clients ask how security updates and general patches
are applied to embedded products built using Yocto.

The Yocto Project, via it's contributors usually provides support for the -two- releases + master.

That means effectively a one year community (best-effort) support model for each release. So today that would be 1.5 and 1.6. (Master is continuously developed, and I'd expect any relevant fixes to go there as well.)

Note, this is all contingent upon contributions from Yocto Project members and the Open Embedded community at large. Without contributions, there is no support.

That's true, and I've always been very impressed with the number and quality of the contributors to YP. It's a really good case-study to throw at those who say opensource doesn't work or make commercial sense ;-)

If they're really embedded, then the only way to to this is by replacing the

rootfs - especially when they boot read-only.

See the million threads on "field upgrade". There is no one answer. Device upgrade, Image upgrade, package upgrade, and file upgrades are all possibilities... but these need to be built into the device during it's design. There are no best practices available, as everyone seems to have different requirements.

Yes, I've followed a few of those with interest. We've moved to a model of using iPXE to network boot (we have a closed client-server system) a read-only image to make it easier (for us).

A second complication is when support for a BSP gets dropped so later

versions, which generally include updates and patches, can't be used.

If you are releasing a product, you shouldn't be expecting to migrate (in a product lifecycle) from YP 1.4 to YP 1.5 to YP 1.6, etc. Each release is individual, and an overall target based upgrade and BSP obsolescence is not part of the project. This is really the realm of the device manufacturer, OSV and other commercial vendors of YP components.

That's how I try and work, sticking with a single version of YP until a major version change of our application or we need to switch to different hardware. A bit of layer management is all that's been needed so far to allow me to build for different hardware.

It feels to me as if there should be some "LTS" releases which developers

could focus on when choosing a version.

It all comes down to contributions in the end. If nobody is contributing, don't expect updates. There has been talk over time of an LTS type release. I've heard everything from extending the 1 year to '2' years.. or as contributions are available.

But if you want long term support, your best bet is to find an OSV (or other Yocto Project participant) that is willing to do long term support and maintenance of a product.

(Speaking for Wind River for a second, we do offer extended support for many many more years then what I would ever expect the community to support. I would expect the same from our competitors.)

Or is there already some way of doing this that I just haven't spotted?

This is where community support really transitions to commercial. The community is interested in enabling new designs and 'maker' projects. Commercial is interested in building products and long term support. (IMHO, others might disagree.)

Basically, this all fits with my expectations / understanding. I can now show clients that I am talking about "the real world" (TM) and not simply trying to add support costs ;-)

However, I still need to work at convincing people that it's not always as simple as updating one package as the update can have knock-on effects else where - which is why a "simple" update can end up being very time consuming and/or costly to implement.

One option may be to convince them that it'll be cheaper to upgrade the hardware at the same time if the best option is to move to a newer YP version and it does not include the BSP that's required.

Chris Tapp

opensource@...
www.keylevel.com

On 08.05.2014 23:00, Chris Tapp wrote:

However, I still need to work at convincing people that it's not always as simple as updating one package as the update can have knock-on effects else where - which is why a "simple" update can end up being very time consuming and/or costly to implement.

"Mystical man month"

You need more that a hacker in a garage to build a system of software
infrastructure.

Best regards
Michael

On 05/08/2014 02:53 PM, Michael Stickel wrote:

On 08.05.2014 23:00, Chris Tapp wrote:

However, I still need to work at convincing people that it's not always as simple as updating one package as the update can have knock-on effects else where - which is why a "simple" update can end up being very time consuming and/or costly to implement.

"Mystical man month"

You need more that a hacker in a garage to build a system of software
infrastructure.

But the Yocto Project does make it easier for him :)

Philip

Best regards
Michael