Lines Matching refs:a

15    discovery of a new file in /tmp/images by Image Manager.
17    requires write access to filesystem. This poses a security risk.
29 1. Able to start an update, given a firmware image and update settings.
38    a firmware update.
129 - Each upgradable hardware type may have a separate daemon (\<deviceX\> as per
177 Images will be kept in memory and passed to \<deviceX>CodeUpdater using a file
187 update. Also, a phosphor-logging event will be created and sent back to client
197 \<deviceX>CodeUpdater may be a device specific daemon, vendor may choose any
207 component image. In such a scenario, \<deviceX>CodeUpdater can create a logical
230   different <deviceX>CodeUpdater daemons or by a single daemon for hardware
247 path for a version update which will help to block any interruptions from
251 Moreover, when a device is being upgraded the sensor scanning for that device
282 - Imposes the need of a common image format as Software Manager needs to parse
284 - Limitation in the design, as there is a need to get the current running
290 The proposed solution uses a push model where status and progress updates are
291 asynchronously pushed to BMCWeb. Another alternative would be to use a pull
297 - Server doesn't have to maintain a Dbus matcher
324 ### Does this design require a new repository?
326 Yes. There will be a device transport level repositories and multiple
328 repository. For example, all devices using PMBus could have a common repository.