Re: [ptxdist] PTXdist usescases

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

Hi,

Am Donnerstag, den 30.08.2018, 11:41 +0200 schrieb Michael Olbrich:
> On Thu, Aug 30, 2018 at 08:05:04AM +0000, Baeuerle, Florian wrote:
> > Am Mittwoch, den 29.08.2018, 16:48 +0200 schrieb Michael Olbrich:
> > > 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?
> 
> It's a diff. If you run e.g. a menuconfig in on layer the it will basically
> take the config from the lower layer, applies the diff before actually
> running menuconfig. When you're done, a new diff is created.
> 
> So each layer can add new packages and enable or disable existing packages.
> 
> > +-------------------------+-------------------------+ 
> > >                         |                         |
> > >       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.
> 
> That should be easy with layers: The base layer contains all the common
> stuff (for platforms, ptxconfig etc.). After changing something in the base
> layer you just need to run oldconfig in each App layer.
> 
> > > > 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.
> 
> Add platform-opengl and the extra packages to the platformconfig and add
> the dependencies there. If platform-opengl is enabled in both configs, then
> any dependencies will be handled correctly.
> 
> > 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)?
> 
> Add the symbol to the platformconfig.

Is there a way to do this so that the (manually?) added symbol survives a
"ptxdist menuconfig platform"?

> 
> > > > 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?
> 
> My current plan is to get this ready for the October release. So if all
> goes according to plan then the code should hit the repository sometime in
> September.
> 

Cool, waiting eagerly for it :)


Florian
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de