hi Igor; > On 29 November 2013 17:07, Aliaksei Katovich <a.katovich at samsung.com> > wrote: > > > hi all; > > > > I would like to bring to your attention Tizen system rollback > > feature. > > The idea is to provide possibility to roll back Tizen based system > > to > > one of several known working configurations. Most obvious > > use-cases are: > > > > * system update or upgrade failed; > > * there are regressions introduced by system update; > > * User does not like features added by system update; > > * User wants to restore device to first time configuration; > > * User wants to restore device to factory defaults. > > > > Proposed architecture is based on device-mapper thin-provisioning > > capabilities. Please find more details in attached document. > > > > Before starting actual implementation of this feature I would like > > to > > hear your opinion about presented architecture and the idea in > > general. > > > > I see some reasons why part of these options are unfeasible/undesirable > under certain circumstances: > > * user has subsidized device > If a way is found to break the simlock for a certain SW revision, the > operator should > be able to forcibly update all the units deployed in the field that are > made available w/ subsidy. > The user should not be able to rollback to some unlockable version.
Fair enough. > * hole in DRM scheme is found > This is a bit similar to the previous case but applies to both locked and > unlocked devices. > If a certain SW version is found to be exploitable for cracking DRM > content, the OEM/operator > should have the means to issue (possibly) non-mandatory irreversible > updates. > I'm not a lawyer but I suppose that neither OEM nor operator have the > rights to impose a SW update > on user-owned devices, however they can easily make it so that the > following user-issued upgrade > prevents any rollback. Preceded by some warning, of course. > > So I think there should be means to forcibly and voluntarily permanently > flush the queue or > prevent any rollback, from before a certain version. I reckon these two are more of a policy and are barely related to rollback mechanism itself (which I personally would like to focus on) though good to discuss too. That said, subsidized devices and devices with DRM dependencies can have certain anti-rollback rules. > Furthermore, I think it's not such a great idea to tie factory settings and > overall device status. > I would prefer if each SW update would also include its own specific set of > "clean slate" configuration values. Here are my thoughts regarding your preference: * solution is not universal and is tight to certain implementation of system update which can/will undergo evolutionary changes - hence how to deal with compatibility issues; * it might turn out that "clean state" solution will be way too complicated as it has to deal with several update generations (think of all dependencies); * how to deal with 3rd party updates that might come without "clean state" set; * how much extra space will be required to maintain "clean state" of each update; remember device-mapper provides thin-provisioning out of box. > Without talking about factory. I would not discard a possibility to do factory reset. > Red Hat, afaik, targets different type of products where these issues are > not present. Sure, but frankly I do not think this prevents us from having policies independent rollback mechanism in Tizen. Besides, to my knowledge Tizen targets at being more than just mobile platform. Though I might be wrong about the latter. -- Aliaksei > > -- > cheers, igor > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.tizen.org/pipermail/dev/attachments/20131129/44f30375/attachment.html> > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
