ubuntu-phone team mailing list archive

[Stéphane Graber <stgraber@xxxxxxxxxx>]

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 <jamie@xxxxxxxxxxxxx>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 <ogra@xxxxxxxxxx
> > > <mailto:ogra@xxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
> > >     <mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
> > >     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@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ubuntu-phone
> > More help   : https://help.launchpad.net/ListHelp
> >
> >

-- 
Stéphane Graber
Ubuntu developer
http://www.canonical.com

Attachment: signature.asc
Description: Digital signature