Hi, > On Apr 7, 2016, at 2:27 PM, ray suorsa <[email protected]> wrote: > ... > 2) I have one feature request or maybe it is a design change. > Currently the when talking to the OS and getting a list of images > it replies with the version of the image. Versions are fine and > I think the OS needs to reply with version info. However I think > the images should be indexed and stored via the firmware image’s > embedded buildid. I would like the buildid to be The-One-True-Id > for a build. Given that it is a SHA256 of the firmware it would > be exceedingly rare to have a SHA256 collision vs having collisions > in user supplied versions. Therefore if the image list could reply > with something like: > > { > "Images": [ > [“f50200f8256235434440c73dc79705daf1462d23395e7b6e0f299a78946b5159”, > “1.2.3.4"], > [“7723a4bad19e23989ba4dad1b593e44a950a7fe9b10163fdd25a577454caf9e2”, > “1.2.3.4"] > ] > } > > or even, > > { > "Images": [ > “f50200f8256235434440c73dc79705daf1462d23395e7b6e0f299a78946b5159:1.2.3.4", > “7723a4bad19e23989ba4dad1b593e44a950a7fe9b10163fdd25a577454caf9e2:1.2.3.4" > ] > } > > then we have good visibility into what the device really has. >
Getting back to this. I like the idea (except for the above listing having different hash for same version image :) I don’t think there’s much benefit in keeping the backwards compatible command/response support around. No users for this yet, really. So I’m thinking that I would just replace the existing commands with this. Code space is precious. Unless there’s a compelling reason to do so. Let me know, M
