RE: swupdate : support for patch based update

[Viswambharan, Vibin (V.)]

Hi Stefano. Helpful ,comprehensive feedback. Yet ,a couple of clarifications from my side...
Thanks for the quick response...

--Vibin

-----Original Message-----
From: Stefano Babic [mailto:sba...@denx.de]
Sent: Thursday, July 30, 2015 1:29 PM
To: Viswambharan, Vibin (V.)
Cc: sba...@denx.de
Subject: Re: swupdate : support for patch based update

Hi Vibin,

On 30/07/2015 08:54, Viswambharan, Vibin (V.) wrote:
> Hi Stefano. I am Vibin ,working in the automotive embedded domain. Last week I was going through the
> implementation of SWUPDATE especially on the support provided by the
> implementation for downloading images from a remote server and perform
> target flashing.
>
>

ok

>
> I have a related query with this ,but not very specific to swupdate.
> Did you came across with any request or suggestion to support the
> "patch based upgrade"?. I have seen your documentation have some
> strong point of caution towards using package managers for software
> updates in embedded targets. Would you be able to share your thoughts
> on extending the swupdate to support a way to upgrade the existing
> images using patch.
> Do you see any issues with this approach or something that you have
> evaluated before.

Have you check my slides ?

http://events.linuxfoundation.org/sites/events/files/slides/SoftwareUpdateForEmbedded.pdf

Or even:

Updating Embedded Linux devices in field by Chris Simmonds

http://de.slideshare.net/chrissimmonds/linux-fieldupdate2015

In the slides, I explain my concerns about an additive upgrade. Of course, customers ask for reducing size of the download image. But the big difference is if the upgrade *should* work in most case or *must* work *always*.


If you upgrade the system modifying the filesystem, as you suggest and as the package managers are doing, you rely on the fact that the filesystem is in a well known state. How do you know that ? Even if the filesystem is read-only, there are cases where flash goes corrupt and something is not anymore as you delivered. For example: a single library is corrupted. You note this only when a program linked with the library is loaded.

[Vibin] : Yes ,I did go through your presentation on SoftwareUpdate ForEmbedded.pdf. Though I anticipate some these issues ,but I was not that clear. Your response *should* work vs *must* work *always* conveys a lot more than what I thought about on things that could go wrong...

> Is solutions like XPatch could be used to

I know xdelta, but xpatch is a new term for me, and searching in internet did not help me. What is this ? Do you have a link ?

[Vibin] : Sorry its a mistake from my editing, I was just putting Xdelta,bspatch etc...so somehow I made Xpatch out of my editing...

> generate the filesystem image diff as a patch, which can be applied to
> the target image by swupdate?.

This is what xdelta provides. swupdate is flexible, and it is possible to write a handler able to install xdelta (xpatch ?) subimage.

I have my doubts, but the final decisions is taken by the customers. If some of them decides to go for a differential upgrade and ask for such a solution, I will implement a suitable handler. But he must have the whole visibility and checks for pros and cons.

As I said, anyone should check for his own project which are the goals:
reliability against speed or comfortability.

[Vibin] : I agree ,neither we can't sacrifice reliability for speed...Soon or later we will have to pay off the penalty for that...

> I see this as an option to reduce the
> image size and optimize bandwidth while swupdate is supporting
> scenarios like flashing software over the air usecase.

But you have to rely on a working filesystem. Can you explain what happens when an upgrade with xpatch failed, and the filesystem remains in a unknown state ?

> But I am not sure
> whether there are reliable and secure implementations that can work
> for the generation and application of patched suited to the embedded
> targets image upgrades?. Please share if you have some insight on this.

You have to define the scenarios and check with the projects. There is no general solutions.

Of course, if you use swupdate in a double-copy scenario (see documentation), and there are two copies of the software on the target, even a package manager or xdelta/xpatch solution can be safe enough.
In this case, a differential upgrade can make sense.

[Vibin] : I wrote about this , after seeing that swupdate provides the double-copy scenario. Though I am not yet there to confirm whether we can deploy the double copy strategy for all the images, as it is going to cost us more in terms of storage memory and update logic to manage them. We must to the minimum afford to keep bootloader, kernel recovery copies to guarantee and ensure there is always a means to get access to the system for upgrade .But I think it may not be viable to reserve storage for rootfs image which is relatively huge in resource demands.

With a rescue/single copy, the risk to brick the target remains IMHO too high.

[Vibin] : This is a good thought provoking question. This again brings me back to the question of how can we do the incremental updates always in an atomic, fail safe way?.

>
>
>
> Thanks in advance. I didn't use the mailing list as the information I
> am looking is bit out of the core topic.

I have not CCed to ML, but this is also a topic for a general discussion. Do not feel afraid and post your question to the ML. Maybe someone else as me can add some valuable informations.

[Vibin] : Also one more question , I appreciate the fact that a lot of thought has been put it into while shaping up this framework and infact it is structured fairly well to adapt various use cases related to flashing. Again respecting the decisions on this as I see today ,my questions,

1. Has this been discussed/shared to automotive IVI alliances like Genivi,AGL ?.
2. The some constraints we will run into while using this under GPL terms, as in our domain there are cases we have to consider the devices/nodes external to our system and some of them have to follow proprietary communication /device commands protocols for device updates. This may constrain us in creating "device specific update" handlers as part of the swupdate core process . I see some extension ,yet to go in details ,about the proposal to use "ipc" mechanism to interact with the daemon. Is this approach can be used to "blackbox" the update handlers as separate process and get them registered with the daemon for update purpose? .Is there a way to solve this?.


Best regards,
Stefano Babic


--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =====================================================================

[Stefano Babic]

Hi Vibin,

On 31/07/2015 08:52, Viswambharan, Vibin (V.) wrote:
> Hi Stefano. Helpful ,comprehensive feedback. Yet ,a couple of clarifications from my side...
> Thanks for the quick response...
>
> --Vibin

>

>> But I am not sure
>> whether there are reliable and secure implementations that can work
>> for the generation and application of patched suited to the embedded
>> targets image upgrades?. Please share if you have some insight on this.
>
> You have to define the scenarios and check with the projects. There is no general solutions.
>
> Of course, if you use swupdate in a double-copy scenario (see documentation), and there are two copies of the software on the target, even a package manager or xdelta/xpatch solution can be safe enough.
> In this case, a differential upgrade can make sense.
>
> [Vibin] : I wrote about this , after seeing that swupdate provides the double-copy scenario. Though I am not yet there to confirm whether we can deploy the double copy strategy for all the images, as it is going to cost us more in terms of storage memory and update logic to manage them. We must to the minimum afford to keep bootloader, kernel recovery copies to guarantee and ensure there is always a means to get access to the system for upgrade .But I think it may not be viable to reserve storage for rootfs image which is relatively huge in resource demands.

This is exactly the trade-off to pay. A double-copy scenario allows even
to update the system in service. swupdate is integrated in the rootfs
and triggered by upgrading. Some systems, mainly in telecom, need this.

This costs a lot about resources. It does not make sense to have two
copies of *some* parts of the software, you have to double *everything*
to be safe, including, of course, root filesystem.

>
> With a rescue/single copy, the risk to brick the target remains IMHO too high.
>
> [Vibin] : This is a good thought provoking question. This again brings me back to the question of how can we do the incremental updates always in an atomic, fail safe way?.

My point of view is that on embedded systems is much more safer to
upgrade the whole software as parts of it. This saves the system even
after the main system was damaged. Of course, a strong analysis of the
projects taking into account type of storages, scenarios, and so on,
must be done.

To reach a safe incremental update, the current system must be validate.
This means not only, for example, that package managers can successfully
update some packages, but even that was not updated is in a well known
state. IMHO there must be high constraints about bandwidth in case of
remote upgrade to go on on this way.

>
>>
>>
>>
>> Thanks in advance. I didn't use the mailing list as the information I
>> am looking is bit out of the core topic.
>
> I have not CCed to ML, but this is also a topic for a general discussion. Do not feel afraid and post your question to the ML. Maybe someone else as me can add some valuable informations.
>
> [Vibin] : Also one more question , I appreciate the fact that a lot of thought has been put it into while shaping up this framework and infact it is structured fairly well to adapt various use cases related to flashing.

Thanks.

> Again respecting the decisions on this as I see today ,my questions,
>
> 1. Has this been discussed/shared to automotive IVI alliances like Genivi,AGL ?.

No. I presented and discussed this project on the Yocto ML. However,
Genivi is very active with Yocto and meta-swupdate can be easy used with
other meta layers, as the ones for automotive.

> 2. The some constraints we will run into while using this under GPL terms, as in our domain there are cases we have to consider the devices/nodes external to our system and some of them have to follow proprietary communication /device commands protocols for device updates. This may constrain us in creating "device specific update" handlers as part of the swupdate core process . I see some extension ,yet to go in details ,about the proposal to use "ipc" mechanism to interact with the daemon. Is this approach can be used to "blackbox" the update handlers as separate process and get them registered with the daemon for update purpose? .Is there a way to solve this?.

My work is in Open Source and the company I work is very active to
promote FOSS projects: swupdate is GPL.

However, I know the issue and I have already provided a way for soving
it. It is not done with the IPC interface. This is thought to extend the
interfaces to get the compound image. Let's say, you do not use a
standard protocol (HTTP/FTP/..), but you have a proprietary application
to transfer the image. You can write your own proxy and route the
packets to swupdate via IPC.

Your Use Case is covered by the LUA handlers. LUA is a very powerful
script language (if you do not know, it is worth to take a look) and it
has a very small footprint. There is a mechanism in swupdate to rely on
external (not linked to swupdate) handlers. Handlers are written in LUA,
and you can implement your protocol as you want. It remains a script
that is loaded on demand by swupdate and interpreted at runtime. You can
write any extensions you want.

There is a small example in the sources. This explains mainly the
interface between swupdate and a LUA handlers. It should as Use Case
shows the upgrade of a FPGA via a undefined protocol - this approach
covers your use case.