[meta-ti] [PATCH 1/3] matrix-gui-browser: port from arago overlay

[Maupin, Chase]

> -----Original Message-----
> From: meta-ti-bounces at yoctoproject.org [mailto:meta-ti-
> bounces at yoctoproject.org] On Behalf Of Koen Kooi
> Sent: Friday, January 27, 2012 2:54 PM
> To: meta-ti at yoctoproject.org
> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from
> arago overlay
> 
> 
> Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende
> geschreven:
> 
> > On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote:
> >>> -----Original Message-----
> >>> From: Mills, William
> >>> Sent: Friday, January 27, 2012 2:11 PM
> >>> To: Maupin, Chase
> >>> Cc: Koen Kooi; meta-ti at yoctoproject.org
> >>> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port
> from
> >>> arago overlay
> >>>
> >>>
> >>> On 01/27/2012 02:46 PM, Maupin, Chase wrote:
> >>>> I guess we have a difference of opinion on how we see meta-
> arago.
> >>> I
> >>>> don?t separate that layer into distro and non-distro. I was
> >>> really
> >>>> planning on meta-arago being all the stuff related to the
> >>> arago/SDK
> >>>> distribution. Meta-ti is for TI packages that can be used by
> >>> other
> >>>> distros. That being said I'm OK with meta-ti being split into
> a
> >>> BSP
> >>>> layer and everthing else, but I don't know exactly what that
> buys
> >>> us.
> >>>> Does it particularly hurt someone that pulls in meta-ti to
> have
> >>> access
> >>>> to matrix if they don't use it? I pull in things from meta-oe
> or
> >>>> oe-core that I don?t "need" but they are there anyway.
> >>>
> >>> Do you know that everything you are putting in meta-ti today
> only
> >>> depends on oe-core?  I don't think you do as we are not testing
> >>> that
> >>> today.  Yes, in the old days a recipie collection had tons of
> stuff
> >>> that
> >>> would be present but just fail if you actually tried to use it.
> >>> The
> >>> point of layers was to clean that up.
> >>
> >> Not sure what your comment about only needing oe-core is.  For
> example I use
> >> lmbench but I don?t see that in oe-core.  I get that from meta-
> oe.  I can
> >> agree to spliting meta-ti into two layers, a HW layer for our
> devices and a
> >> layer containing all of the TI recipes.
> >>
> >> But if we wanted to match the meta-intel layer way would you
> also propose
> >> making a layer per device?  I personally find that more
> confusing.
> >
> > I don't think that was Bill's message. It was simplicity. BSP
> only layer, no
> > supplemental apps, if not absolutely required.
> >
> > Your example with lmbench is not correct - BSP layer should be
> simple enough
> > to be used with OE-Core alone to produce a console rootfs image
> with nothing
> > but busybox.
> >
> > How about splitting meta-ti into:
> > * BSP only
> > * SGX graphics
> > * DSP tools
> 
> Since sgx and dsp are built into the SoC, why isn't it considered
> BSP? I must really start warming about getting overzealous with
> layers and breeding a silo mentality. I'm not saying we only need
> one layer, but not a gazillion like the base proposal.

I did not read the above as making a bunch of layers in meta-ti.  At the risk of getting this all started again, I really hope meta-ti is one layer with BSP, SGX, DSP, WiFi support for our devices.  

> 
> _______________________________________________
> meta-ti mailing list
> meta-ti at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti