Re: [Fud] documents and minutes

Erik Nordmark <nordmark@sonic.net> Wed, 19 April 2017 21:24 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745DA12E852 for <fud@ietfa.amsl.com>; Wed, 19 Apr 2017 14:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level:
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J3Pd1XLdSWL for <fud@ietfa.amsl.com>; Wed, 19 Apr 2017 14:24:51 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC28129C6B for <fud@ietf.org>; Wed, 19 Apr 2017 14:24:51 -0700 (PDT)
Received: from [192.168.254.146] (72-172-185-194.bayarea.net [72.172.185.194]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3JLOj2Y014129 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 14:24:48 -0700
To: Michael Richardson <mcr+ietf@sandelman.ca>, fud@ietf.org
References: <18203.1492362438@obiwan.sandelman.ca>
From: Erik Nordmark <nordmark@sonic.net>
Message-ID: <81f70fb8-1ed7-6e86-4c7b-d4ab20ae8d47@sonic.net>
Date: Wed, 19 Apr 2017 14:24:45 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <18203.1492362438@obiwan.sandelman.ca>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVZaM7MwsO+47R7xCwT6KZ1hte2vErU9UJ9811y9CjqwR1GvtA1mS32SOUO+7QSsQicU45jBxNqQDQVcLWKG1L/18wenFCtStF8=
X-Sonic-ID: C;duxRnEYl5xG2GyzL7bdh1w== M;VjLVnUYl5xG2GyzL7bdh1w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/SqaJtr7rZYtOUGLnADBnaFqsH9s>
Subject: Re: [Fud] documents and minutes
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 21:24:52 -0000

On 04/16/2017 10:07 AM, Michael Richardson wrote:

>
> I wanted to take issue with the way this distinction is being presented.
> While there are plenty of Linux based systems that do updates via packages,
> and systems like OpenWRT/LEDE and Android that can load some optional
> components via packages (opkg and apk), many of these systems do their
> primary upgrades via complete firmware replacements.
>
> It's not about "M-class" vs "A-class" (some very ARM specific terminology), at all.

Agreed.

>
> The only difference between an RPI-IoT device running Android and an ATmega
> running Ardiuno or Freescale or OpenMote device running Contiki is the number
> of megabytes the image is.  The large image devices actually have more of a
> challenge because they usually can not double-buffer the image, so they have
> more in common with the very small devices, with the "M-class" device
> actually being richer than then the smaller devices.

I think there is a distinction between devices which have an MMU (memory 
management unit) vs. not which can have some impact on software update.
A device with an MMU can more easily put together different pieces of 
software using virtual memory.
A device without an MMU either has to replace the whole firmware, or do 
additional work should one upgraded piece grow in size. (I the bar the 
observation was that one can use position independent code and move some 
code around to make room, or leave dead space in the image to allow for 
some growth.)

It would be nice to have an image format which could allow for those 
differences when allowing for updating only the pieces which change from 
one version to another.

    Erik