Update "sw-versions" or "hwrevision" file

[keisuke...@miraclelinux.com]

Hi,

To my understanding, "/etc/sw-versions" or "/etc/hwrevison" is not updated unless I expressly indicate to do so in .swu file or postinstall script as a .sh or lua and so on. Is it right? 

Is there any other way to update them automatically?

Best regards,

Keisuke

[Stefano Babic]

Hi Keisuke,

On 31/07/19 08:55, keisuke...@miraclelinux.com wrote:
> Hi,
>
> To my understanding, "/etc/sw-versions" or "/etc/hwrevison" is not
> updated unless I expressly indicate to do so in .swu file or postinstall
> script as a .sh or lua and so on. Is it right?

In my understanding, you have not understood.

The hwrevision file (or the -H parameter) should not be updated in this
way. Can you upgrade the hardware with a software update (excluded FPGA.
please) ? It would be nice, SWUpdate has a lot of features, but I guess
this should not be possible...

hwrevision should be generated after detecting which is the board
revision of the hardware. It is not an artifact, it is an input for
SWUpdate to check if the release is compatible with the hardware.

sw-versions could be part of rootfs - but then, should it be ? If the
bootloader can be updated, its version must be detected because
bootloader is not often upgraded and releases can run on boards with
different versions of bootloader.

> Is there any other way to update them automatically?

It does not make sense.

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
=====================================================================

[motomasa...@miraclelinux.com]

 Hi Stefano,

I'm Motomasa and a co-worker of Keisuke from Cybertrust Japan.

Please let me add more information.  Based on that,  I would like to confirm 

the design concept of SWUpdate.

 

> Is there any other way to update them automatically?

It does not make sense.

In my understanding, a certain operator, administrator or related someone 

of the SWupdate running device should be responsible for appropriately 

updating "/etc/hwrevision" or "/etc/sw-versions" when it updated 

as no matter what to hardware or software. The responsibility should not 

be belonged to SWUpdate.

Therefore we, device administrator can freely define and write 

a "/etc/hwrevison" or "/etc/sw-versions". instead of this, 

we have the responsibility of managing them.

If I'm wrong, could you correct me?

Best regards,

Motomasa SUGIYAMA

===============================================

Motomasa SUGIYAMA

IoT Development Dept.

Cybertrust Japan Co.,Ltd.

E-mail: motomasa...@cybertrsut.co.jp

URL: 

https://www.cybertrust.co.jp/english/

https://www.cybertrust.co.jp/english/iot/

===============================================

[Stefano Babic]

Hi Motomasa,

On 01/08/19 12:06, motomasa...@miraclelinux.com wrote:
>  Hi Stefano,
>
> I'm Motomasa and a co-worker of Keisuke from Cybertrust Japan.
>
> Please let me add more information.  Based on that,  I would like to
> confirm 
> the design concept of SWUpdate.
>  
>
> > Is there any other way to update them automatically?
>
> It does not make sense.
>
>
> In my understanding, a certain operator, administrator or related someone 
> of the SWupdate running device should be responsible for appropriately 
> updating "/etc/hwrevision" or "/etc/sw-versions" when it updated

Updating /etc/hwrevision means you are updating the Hardware, and this
means in most cases you are replacing an old or defect hardware.

/etc/hwrevision should be generated by reading from Hardware and
detecting a board revision, or something like that. There is no standard
mechanismus to do this (GPIOs ? I2C ? Something else ?) and the
responsibility to do it is outside SWUpdate.

/etc/sw-versions belong to software. But as I explained before, you can
an old bootloader running a new release of software, and you decided
just later to replace the bootloader. And you do not want that the
bootloader is replaced on all devices in field because it could be
risky, so just in case the bootloader is too old.

 > as no matter what to hardware or software. The responsibility should not 
> be belonged to SWUpdate.

Right - the responsibility does not belong to SWUpdate. It is just an
input for SWUpdate.

>
> Therefore we, device administrator can freely define and write 
> a "/etc/hwrevison" or "/etc/sw-versions".

Yes, as I explained before. Please also note that sw-versions can be
used, but it is not duty. It just avoid to update risky artifact like a
bootloader. SWUpdate just skips the install of an artifact if version is
the same.

> instead of this, 
> we have the responsibility of managing them.
>

I have not well understood last sentence, I do not know what you mind
with "managing them".

> If I'm wrong, could you correct me?
>

Best regards,

Stefano Babic

> Best regards,
> Motomasa SUGIYAMA
>
>
> ===============================================
> Motomasa SUGIYAMA
> IoT Development Dept.
> Cybertrust Japan Co.,Ltd.
> E-mail: motomasa...@cybertrsut.co.jp
>
> URL: 
> https://www.cybertrust.co.jp/english/
> https://www.cybertrust.co.jp/english/iot/
> ===============================================
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/d708076e-c1f2-41d8-b62b-e977262cbbdf%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/d708076e-c1f2-41d8-b62b-e977262cbbdf%40googlegroups.com?utm_medium=email&utm_source=footer>.

[motomasa...@miraclelinux.com]

Hi Stefano,

Thank you for quick reply.

The generating concept of /etc/revision which I assumed is mostly 

the same as you explained. /etc/sw-versions is as well. As you explained, 

I know the risk of updating a bootloader remotely.  We're going to design 

appropriately the device and OTA updating service by using a strategy 

of the dual copy with /etc/sw-versions.

> instead of this, 
> we have the responsibility of managing them.
>

I have not well understood last sentence, I do not know what you mind
with  "managing them".

the "managing them" means /etc/hwrevision and /etc/sw-versions are 

under the administration of us as a device administrator. It is a kind of 

the trade-off relationship. we have a right to freely define and write them. 

Instead of it, we also have a responsibility to appropriately update them.

We'd like to use SWUpdate as a part of our secure IoT products. 

Of course I know the GPL2.0+ license well.

https://sbabic.github.io/swupdate/licensing.html

Would you mind if we ask more technical matters at this Google group later? 

Or we should email to sba...@denx.de?

[Stefano Babic]

Hi Motomasa,

On 01/08/19 14:40, motomasa...@miraclelinux.com wrote:
> Hi Stefano,
>
> Thank you for quick reply.
>
> The generating concept of /etc/revision which I assumed is mostly 
> the same as you explained. /etc/sw-versions is as well.

Ok

> As you explained, 
> I know the risk of updating a bootloader remotely.  We're going to design 
> appropriately the device and OTA updating service by using a strategy 
> of the dual copy with /etc/sw-versions.
>
> > instead of this, 
> > we have the responsibility of managing them.
> >
>
> I have not well understood last sentence, I do not know what you mind
> with  "managing them".
>
>
> the "managing them" means /etc/hwrevision and /etc/sw-versions are 
> under the administration of us as a device administrator.

Right.

> It is a kind of 
> the trade-off relationship. we have a right to freely define and write
> them. 
> Instead of it, we also have a responsibility to appropriately update them.
>

Ok - yes, it is.

> We'd like to use SWUpdate as a part of our secure IoT products. 
> Of course I know the GPL2.0+ license well.
> https://sbabic.github.io/swupdate/licensing.html

Well, then everything is fine ;-)

>
> Would you mind if we ask more technical matters at this Google group later?

It is a trade-off. This ML is public, anyone can answer if he wants /
have time, including me. This is my "public" support. Exactly as any ML
for FOSS projects.

> Or we should email to sba...@denx.de?

Hopefully you go on this way, this is the commercial support !

Best regards,
Stefano Babic

[杉山元正]

Hi Stefano,

Thank you very much!

First, we'll email you to sa...@denx.de in several days or a few weeks.

if possible we'd like to share that technical matters at this group 

unless it leaks our strategy or related something.