[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Emdebian sprint - flash-kernel discussion



On Wed, Feb 23, 2011, James Westby wrote:
> How would this interact with the proposal for storing some of this
> information in hwpacks?

 This came up; basically linaro-image-tools + hwpacks are one of the
 many copies of this information which we have around.  It will take
 some time to share this stuff across debian-cd, debian-installer,
 flash-kernel, linaro-image-tools + hwpacks etc.

 Basically, we want all these tools to separate code and data, and we'd
 like data to be shared.  Right now, linaro-image-tools has both code
 and data, and moving the board-specific data to hwpacks would be a win.
 Eventually we could generate the hardware pack from this common data,
 or we might change linaro-image-tools to read the common data from
 where it lives, but it seems further away.

 So there's a long-term/short-term tradeoff: hwpack v2 seems possible in
 a couple of weeks, common data package with the right semantics to
 expose ot the world -- might take longer.

> Does it imply that hwpacks aren't quite the right place for this? Should
> they instead just contain an indication of which boards are supported
> and information about the contents (such as the u-boot path), and the
> rest of the information lives outside of the hwpack?

 I'm not sure; for instance consider the case of data which changes with
 the distro over time; let's say linaro-image-tools depends on that data
 and combines the data + 1 hwpack + 1 rootfs to create an image.  Then
 the data changes, and you want to support an older hwpack + rootfs, but
 the new data is not compatible with them (ttyS2/ttyO2 example).  If the
 data is contained in the hwpack in some way, then it's not an issue
 anymore.  I'm pretty sure there are examples the other way around
 though, and I don't like having caches of the data which might be
 stale.

 Also, some data should perhaps be shipped by packages like the kernel
 or by u-boot; for instance a device tree, or the information about the
 kernel features (for instance maybe ttyO2 is a kernel feature we can
 infer from the config).  Hwpacks seem like a convenient vehicle for
 grouping these things together in a daily build which you can download
 and verify easily.

-- 
Loïc Minier


Reply to: