On Thu, Jan 16, 2014 at 02:34:11PM -0500, Chris Wayne wrote: > After some digging around the system, the following types of > device-specific files are currently living in our rootfs: > > - upstart jobs in /etc/init > - udev rules (in /etc/udev/rules.d and /lib/udev/rules.d) > - ubuntu-touch-session configs (basically just telling the system the > number of pixels in a GU IIRC) (in /etc/ubuntu-touch-session.d/) > - lxc container configs (in /var/lib/lxc/android/pre-start.d and > /usr/lib/lxc-android-config/) > - powerd configs (/usr/share/powerd/device_configs/) > - apparmor policies (/usr/share/apparmor/hardware/) > - binaries/scripts (i.e. /usr/bin/brcm_patchram_plus) > - ofono plugins/configs (not in the image now, but there will likely be > device/modem-specific files for these in the future AIUI) > > To get these out of the rootfs, we basically have three options: > > *1) A new hardware-enablement tarball* > > This tarball would be setup similarly to the version.tar.xz, but would hold > all of the device specific config files, udev rules, upstart jobs, etc, and > would be overlaid onto the rootfs. The pros are that by doing this we will > not have to worry about the files being overridden, and it is likely the > easiest to implement. The cons are that this tarball will always be > downloaded/unpacked on every update, which will slow down updates. While > this may not be a problem *yet*, we can't predict a full set of what might > be needed in such a tarball (i.e. what if we needed to include > binaries/libraries not carried in the rootfs, this could end up growing > more than anticipated, therefore slowing down all updates.). This would > also add some level of complexity, that may be confusing OEMs. > > *2) Adding files to the existing device tarball, and overlaying on top of > rootfs* > > This will utilize the device tarball that we already have, and would keep > the update process slightly more simple and easy for OEMs to understand. > The files would simply be overlaid on top of the rootfs (when the image is > being updated, so in RW mode). The main pro here is simplicity. The cons > are that due to the way it's laid out, it would be quite simple to > accidentally overwrite a file contained here by a rootfs update (i.e. we > ship some conf file in this tarball, but then it gets added to the rootfs, > the device-specific file is overwritten). This could be mitigated by > ensuring that we always include ALL needed files in the tarball, regardless > of whether or not they've changed. > > *3) Adding files to the existing device tarball, but unpacking to a > device-only path (like /device or /hwe)* > > This mirrors how the customization tarball works, so all device-only files > would live in one spot (/device, /hwe, whatever we'd decide to call it). > This removes the potential for being overwritten and allows us to have > smaller updates. The con here is that several programs would need to be > patched to look in this new directory (for example, upstart would need to > look in /device, as would apparmor, powerd, udev, etc). > > > As for how the device tarball is updated, I'm not too sure (I know the > custom tarball is built in jenkins from the source of lp:savilerow). > Perhaps Stephane can shed some light here?
Currently the device tarball is generated by the cdimage_device generator directly in system-image by looking for 3 files on cdimage (boot, recovery, system), doing some repacking of those (convert simg to a minimal raw img) and generates a new tarball with them. The unique ID of the tarball is a sha256 of the concatenated sha256 of all 3 input files, which is how system-image detects whether any of them changed. > > > Thanks > Chris > > > On Thu, Jan 16, 2014 at 9:22 AM, Jamie Strandboge <ja...@canonical.com>wrote: > > > On 01/16/2014 08:08 AM, Chris Wayne wrote: > > > My point is that lxc-android-config should even only have *generic* > > container > > > bits. Anything and everything that is device-specific should not be in > > the rootfs > > > > > For the reference hardware (including the emulator), how does one update > > the > > device-specific tarballs if it isn't done in packaging? I'm fine with the > > device > > tarball sprinkling files around, but it seems like Ubuntu devs should also > > be > > able to modify deb packages to update the image so that our images to ease > > development and have an audit trail via the Ubuntu archive. The current > > practice > > is to use lxc-android-config (though it could be something else if people > > wanted > > to change that). Why can't we have a hybrid approach-- debs for reference > > hardware and device tarball for porters and OEMs? > > > > > > > > On Thu, Jan 16, 2014 at 9:04 AM, Oliver Grawert <o...@ubuntu.com > > > <mailto:o...@ubuntu.com>> wrote: > > > > > > hi, > > > Am Donnerstag, den 16.01.2014, 08:58 -0500 schrieb Chris Wayne: > > > > We should still have as little as possible device-specific in > > > > lxc-android-config though, shouldn't we? I'm all for putting > > > > *everything* device specific into the device tarball, otherwise > > it's > > > > simply not maintainable. > > > > > > > well, by definition lxc-android-config holds all bits that are > > container > > > releated (even if they are device specific) ... > > > > > > random device specific changes that are not related to the container > > > stuff should not live in there (even though it is convenient to put > > > stuff there indeed) > > > > > > ciao > > > oli > > > > > > > > > -- > > > Mailing list: https://launchpad.net/~ubuntu-phone > > > Post to : ubuntu-phone@lists.launchpad.net > > > <mailto:ubuntu-phone@lists.launchpad.net> > > > Unsubscribe : https://launchpad.net/~ubuntu-phone > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > > > > > > > > -- > > Jamie Strandboge http://www.ubuntu.com/ > > > > > > -- > > Mailing list: https://launchpad.net/~ubuntu-phone > > Post to : ubuntu-phone@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~ubuntu-phone > > More help : https://help.launchpad.net/ListHelp > > > > -- Stéphane Graber Ubuntu developer http://www.canonical.com
signature.asc
Description: Digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
