Re: [ptxdist] PTXdist usescases

["Baeuerle, Florian" <Florian.Baeuerle@allegion.com>]

Hello Michael,

Am Mittwoch, den 29.08.2018, 16:48 +0200 schrieb Michael Olbrich:
> Hi,
> 
> On Tue, Aug 28, 2018 at 10:07:45AM +0000, Baeuerle, Florian wrote:
> > the way we use ptxdist might be interesting for you as well.
> > 
> > We use one ptxdist directory with two platforms and three applications,
> > let's call the platforms X and Y, and the Applications A, B and C
> > 
> > Application A with two variants on one platform
> >  - release [platform X]
> >  - devel [platform X]
> > Application B with four variants on two platforms
> >  - variant-1-release [platform X, Y]
> >  - variant-1-devel [platform X, Y]
> >  - variant-2-release [platform X, Y]
> >  - variant-2-devel [platform X, Y]
> > Application C with two variants on one platform
> >  - release [platform X]
> >  - devel [platform X]
> > 
> > The devel variant is release + gdb, a few other tools and root login.
> > 
> > Application A, B, C each have their own ptxconfig. Each variant has its
> > collectionconfig. We build the images (squashfs + rauc bundles) with 
> > image packages under each platform directory.
> > 
> > so for building all images for Application B on Platform X, we do this:
> > 
> > ptxdist images \
> >     --ptxconfig=configs/app-B/ptxconfig \
> >     --platformconfig=configs/plat-X/platformconfig
> > 
> > The platformconfig for Platform X has all image packages enabled, but of
> > course we do not want to build image-platform-X-app-A with app-B's ptxconfig,
> > so we put some ifs in the image package makefile, where we check for the
> > currently selected PTXCONF_PROJECT.
> > 
> > What ptxdist misses for our use-case is some sort of collection-like feature
> > for platform-specific things (such as image packages, or platform-specific
> > graphics drivers). With the image packages, we use that workaround, but there
> > could be other use-cases.
> 
> The layer stuff I'm working on may help here.
> 
> The idea is to basically stack multiple BSPs. Files and rules are searched
> last to first much like we do this with BSP/platform/PTXdist already.
> 
> ptxconfig/platformconfig/kernelconfig etc. in the later 'BSPs' are
> more or less a 'diff' to the same config on the next layer.


Sounds interesting, even though I think I do not yet properly understand how it
will work. Is it really a diff, or more like an extension? Can I add additional
packages to an upper layer or can I also deselect them?

+-------------------------+-------------------------+ 
|                         |                         |
|       Platform A        |      Platform B         |
|                         |                         |
+-----------------+-------+-------+-----------------+ 
|                 |               |                 | <- ptxconfig for each
|      App A      |     App B     |      App C      |    application
|                 |               |                 |
|·················+···············+·················+
|                 ·               ·                 | <- not really shared, even 
|       Common packages selected in ptxconfig       |    though the packages are
|                 ·               ·                 |    supposed to be 95% the same
+--------+--------+---+---+---+---+--------+--------+
|        |        | 1 | 1 | 2 | 2 |        |        | <- collections for a bunch of
|  dev   |  rls   | d | r | d | r |  dev   |  rls   |    variants
|        |        | e | l | e | l |        |        |
|        |        | v | s | v | s |        |        |
+--------+--------+---+---+---+---+--------+--------+

I would be happy if I could actually share the third layer in above ASCII drawing.

That basically is the common stuff that should end up on all images (systemd, busybox
configuration, etc.). It's supposed to be the same everywhere, but they cannot be
trivially kept in sync.

> 
> > Let's say I want to build App D on two platforms, each requiring different
> > graphic drivers (SGX is a nightmare), I wouldn't really know how to do that
> > properly.
> 
> Hmm, we have something like this already: The 'platform-opengl' package
> defaults to Mesa, but you can a platform specific rule in each platform. I
> used this in the past for Mesa vs. Vivante.

That would, however, only work if it would be one package?
For am335x with gpu, I need three packages: the OOT kernel module, a franken-patched
libgbm and the blobs (libEGL, GLES, libpvr*, etc.).

When i override platform-opengl through configs/platform-a, then these three packages'
symbols would end up in my ptxconfig, so my ptxconfig is more or less tied to my platform.

Besides: is there a way to just "by default" select and install a package for a given
platform (without having the symbol in the ptxconfig)?

> 
> > The problem otherwise could be solved by using one ptxconfig that selects many
> > many packages as module. That, however, turned out to be a bit too complex,
> > because there are quite a few differences between the dependencies of App A, B
> > and C. Further, there are things that are bool instead of tristate that you
> > might not need/want.
> 
> The layers might help here too.

I'm curious, when can we expect it to see them in the ptxdist repository?



Florian
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de