Re: [Fud] Charter Text

Olaf Bergmann <> Tue, 08 August 2017 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30BA8132324 for <>; Tue, 8 Aug 2017 03:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l64fz6Y0DTHc for <>; Tue, 8 Aug 2017 03:50:24 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA444132321 for <>; Tue, 8 Aug 2017 03:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( [IPv6:2001:638:708:30c9::b]) by (8.14.5/8.14.5) with ESMTP id v78AoIpG006043; Tue, 8 Aug 2017 12:50:18 +0200 (CEST)
Received: from (unknown [IPv6:2001:638:708:301:224:d6ff:fe13:2040]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3xRWQ221CWzDLHj; Tue, 8 Aug 2017 12:50:18 +0200 (CEST)
From: Olaf Bergmann <>
To: Hannes Tschofenig <>
Cc: Emmanuel Baccelli <>,
References: <> <> <> <>
Date: Tue, 08 Aug 2017 12:50:18 +0200
In-Reply-To: <> (Hannes Tschofenig's message of "Tue, 8 Aug 2017 12:39:16 +0200")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Fud] Charter Text
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Aug 2017 10:50:26 -0000

Hi Hannes,

Hannes Tschofenig <> writes:

> I believe Emmanuel needs to tell us a bit more about the use case he has
> in mind.

And of course others as well. Hannes did a good outline of what he
thinks should be addressed. Those who have use cases that are not
covered by this should speak up.

> The use cases I would like to cover are:
> - a developer creates a single firmware image, which may consist of
> source code from various parties and may also contain binaries from
> third parties.
> - a developer creates multiple firmware images (since the device has
> multiple microcontrollers that need to be updated).
> In this model the update service on a microcontroller gets code from a
> single source only (at least for the device it appears so since it does
> not know whether an included library was written by a different developer).

Yes, I agree in principle.

What we have seen (not only at the IOTSU workshop but also on existing
devices such as VoIP phones) is that firmware updates typically do not
come as a monolithic package but that in modules that can be updated
separately (the most common---and desirable---split is between the OS
and the basic bootloader). I think that at least this should be
addressed here.

> What I specifically want to exclude is a model like JavaScript where you
> can get code from multiple different sources dynamically during code
> execution.

I agree as well.