ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

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 <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
>
>