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? Thanks Chris On Thu, Jan 16, 2014 at 9:22 AM, Jamie Strandboge <[email protected]>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 <[email protected] > > <mailto:[email protected]>> 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 : [email protected] > > <mailto:[email protected]> > > 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
