Layer input

Layer input

[Rifenbark, Scott M]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Hi, 

This next illustration attempting to dive deeper in the YP Development Process takes the remaining left-side input from that figure in the Quick Start (metadata, Machine, and Policy).  Note that when the original figure was created that appears in the QS, the layer stuff had not yet been established.  This figure I am attaching is rough.  I am unsure as to the contents of these layers.  Right now it is detailed but with generic names.  The idea is that individual layers are preferred to do things such as provide software, configure policy, and configure machines.  I am including some notes at the bottom of the figure that would not be part of the figure but might help to get across what I am trying to accomplish here.  

Any suggestions and feedback is really appreciated.  

Thanks, 
Scott

Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)



[-- Attachment #2: layer-input.png --]
[-- Type: image/png, Size: 77674 bytes --]

Re: Layer input

[Bruce Ashfield]

On 13-06-25 08:35 AM, Rifenbark, Scott M wrote:
> Hi,
>
> This next illustration attempting to dive deeper in the YP Development Process takes the remaining left-side input from that figure in the Quick Start (metadata, Machine, and Policy).  Note that when the original figure was created that appears in the QS, the layer stuff had not yet been established.  This figure I am attaching is rough.  I am unsure as to the contents of these layers.  Right now it is detailed but with generic names.  The idea is that individual layers are preferred to do things such as provide software, configure policy, and configure machines.  I am including some notes at the bottom of the figure that would not be part of the figure but might help to get across what I am trying to accomplish here.
>
> Any suggestions and feedback is really appreciated.

I realize you are documenting the Yocto reference builds, so the
explicit reference to linux-yocto*.bbappend makes sense (and I obviously
like it), but a quick tweak might be to just use <name>.bbappend or
<name>.bb (since not all BSP layers must bbappend a kernel, they may
have something very custom) for the kernel recipe reference.

You've already used that notation in the distro layer for the kernel-
headers, so it logically flows.

Cheers,

Bruce

>
> Thanks,
> Scott
>
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Layer input

[Rifenbark, Scott M]

Thanks Bruce.  I will implement that.

>-----Original Message-----
>From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>Sent: Tuesday, June 25, 2013 5:42 AM
>To: Rifenbark, Scott M
>Cc: yocto@yoctoproject.org; Paul Eggleton
>Subject: Re: [yocto] Layer input
>
>On 13-06-25 08:35 AM, Rifenbark, Scott M wrote:
>> Hi,
>>
>> This next illustration attempting to dive deeper in the YP Development
>Process takes the remaining left-side input from that figure in the
>Quick Start (metadata, Machine, and Policy).  Note that when the
>original figure was created that appears in the QS, the layer stuff had
>not yet been established.  This figure I am attaching is rough.  I am
>unsure as to the contents of these layers.  Right now it is detailed but
>with generic names.  The idea is that individual layers are preferred to
>do things such as provide software, configure policy, and configure
>machines.  I am including some notes at the bottom of the figure that
>would not be part of the figure but might help to get across what I am
>trying to accomplish here.
>>
>> Any suggestions and feedback is really appreciated.
>
>I realize you are documenting the Yocto reference builds, so the
>explicit reference to linux-yocto*.bbappend makes sense (and I obviously
>like it), but a quick tweak might be to just use <name>.bbappend or
><name>.bb (since not all BSP layers must bbappend a kernel, they may
>have something very custom) for the kernel recipe reference.
>
>You've already used that notation in the distro layer for the kernel-
>headers, so it logically flows.
>
>Cheers,
>
>Bruce
>
>>
>> Thanks,
>> Scott
>>
>> Scott Rifenbark
>> Intel Corporation
>> Yocto Project Documentation
>> 503.712.2702
>> 503.341.0418 (cell)
>>
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>

Re: Layer input

[Jerrod Peach]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

Scott,

   - Distro Layer
   - I'm unclear on what <name> is.  Is that supposed to be <distro>?
       <recipe>?  It probably shouldn't just be <name>, should it?
   - Software Layer
      - Should COPYING.MIT just be COPYING to be more generically
      applicable?
      - conf/<layer_name>.conf should be just layer.conf, right?
   - BSP Layer
      - COPYING.MIT file again.
      - machine/<name>.conf should probably be machine/<machine*>.conf.
       You can probably drop the non-asterisk version, since an
asterisk implies,
      "There might be more stuff, there might not."
      - recipes-bsp/formfactor shouldn't also have another formfactor
      directory, should it?  Or is the "files" directory in 1.4 replaced with
      another formfactor-named directory?  Also, <name> should be
<machine> again.
      - What's everything from recipes-core down?  I can buy recipes-kernel
      being in a bsp, but are any other directories really necessary?

Kind regards,

Jerrod


On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M <
scott.m.rifenbark@intel.com> wrote:

> Hi,
>
> This next illustration attempting to dive deeper in the YP Development
> Process takes the remaining left-side input from that figure in the Quick
> Start (metadata, Machine, and Policy).  Note that when the original figure
> was created that appears in the QS, the layer stuff had not yet been
> established.  This figure I am attaching is rough.  I am unsure as to the
> contents of these layers.  Right now it is detailed but with generic names.
>  The idea is that individual layers are preferred to do things such as
> provide software, configure policy, and configure machines.  I am including
> some notes at the bottom of the figure that would not be part of the figure
> but might help to get across what I am trying to accomplish here.
>
> Any suggestions and feedback is really appreciated.
>
> Thanks,
> Scott
>
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 3074 bytes --]

Re: Layer input

[Rifenbark, Scott M]

[-- Attachment #1.1: Type: text/plain, Size: 2835 bytes --]

Hi,

I have tweaked this figure some based on Bruce and Jerrod's input.  To help me figure out some of the basics, I ran the yocto-layer and bsp-layer scripts to create a general and BSP layer, respectively.  Please look over the contents of these layers and comment.  General comments on the whole concept of how I am presenting the layers are welcome along with any other observations.

Thanks,
Scott

From: Jerrod Peach [mailto:peachj@lexmark.com]
Sent: Tuesday, June 25, 2013 11:07 AM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org; Paul Eggleton
Subject: Re: [yocto] Layer input

Scott,

  *   Distro Layer

     *   I'm unclear on what <name> is.  Is that supposed to be <distro>?  <recipe>?  It probably shouldn't just be <name>, should it?

  *   Software Layer

     *   Should COPYING.MIT just be COPYING to be more generically applicable?
     *   conf/<layer_name>.conf should be just layer.conf, right?

  *   BSP Layer

     *   COPYING.MIT file again.
     *   machine/<name>.conf should probably be machine/<machine*>.conf.  You can probably drop the non-asterisk version, since an asterisk implies, "There might be more stuff, there might not."
     *   recipes-bsp/formfactor shouldn't also have another formfactor directory, should it?  Or is the "files" directory in 1.4 replaced with another formfactor-named directory?  Also, <name> should be <machine> again.
     *   What's everything from recipes-core down?  I can buy recipes-kernel being in a bsp, but are any other directories really necessary?
Kind regards,

Jerrod

On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M <scott.m.rifenbark@intel.com<mailto:scott.m.rifenbark@intel.com>> wrote:
Hi,

This next illustration attempting to dive deeper in the YP Development Process takes the remaining left-side input from that figure in the Quick Start (metadata, Machine, and Policy).  Note that when the original figure was created that appears in the QS, the layer stuff had not yet been established.  This figure I am attaching is rough.  I am unsure as to the contents of these layers.  Right now it is detailed but with generic names.  The idea is that individual layers are preferred to do things such as provide software, configure policy, and configure machines.  I am including some notes at the bottom of the figure that would not be part of the figure but might help to get across what I am trying to accomplish here.

Any suggestions and feedback is really appreciated.

Thanks,
Scott

Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702<tel:503.712.2702>
503.341.0418<tel:503.341.0418> (cell)



_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto


[-- Attachment #1.2: Type: text/html, Size: 8927 bytes --]

[-- Attachment #2: layer-input.png --]
[-- Type: image/png, Size: 78223 bytes --]

Re: Layer input

[Jerrod Peach]

[-- Attachment #1: Type: text/plain, Size: 4005 bytes --]

Scott,

Getting closer to what I was thinking, but I still have a couple questions,
primarily regarding the BSP layer.

   - There are still a few references to <name>.  Shouldn't those also be
   <recipe>?
   - I'm still confused by the presence of all the specifically-named
   recipes-* directories.  I tried running yocto-layer and I didn't get any of
   those present.  I couldn't find the bsp-layer tool, but I'll grant I didn't
   search really hard.  (I only checked out master of poky and searched around
   a bit.)  What's making you want to put them all in this diagram?

Also, it strikes me that bblayers.conf needs to show up in this diagram
somewhere, I think, since it controls what layers bitbake sees.

Kind regards,

Jerrod


On Thu, Jun 27, 2013 at 3:41 AM, Rifenbark, Scott M <
scott.m.rifenbark@intel.com> wrote:

>  Hi, ****
>
> ** **
>
> I have tweaked this figure some based on Bruce and Jerrod’s input.  To
> help me figure out some of the basics, I ran the yocto-layer and bsp-layer
> scripts to create a general and BSP layer, respectively.  Please look over
> the contents of these layers and comment.  General comments on the whole
> concept of how I am presenting the layers are welcome along with any other
> observations.  ****
>
> ** **
>
> Thanks, ****
>
> Scott****
>
> ** **
>
> *From:* Jerrod Peach [mailto:peachj@lexmark.com]
> *Sent:* Tuesday, June 25, 2013 11:07 AM
>
> *To:* Rifenbark, Scott M
> *Cc:* yocto@yoctoproject.org; Paul Eggleton
> *Subject:* Re: [yocto] Layer input****
>
>  ** **
>
> Scott,****
>
>    - Distro Layer****
>
>
>     - I'm unclear on what <name> is.  Is that supposed to be <distro>?
>        <recipe>?  It probably shouldn't just be <name>, should it?****
>
>
>    - Software Layer****
>
>
>     - Should COPYING.MIT just be COPYING to be more generically
>       applicable?****
>       - conf/<layer_name>.conf should be just layer.conf, right?****
>
>
>    - BSP Layer****
>
>
>     - COPYING.MIT file again.****
>       - machine/<name>.conf should probably be machine/<machine*>.conf.
>        You can probably drop the non-asterisk version, since an asterisk implies,
>       "There might be more stuff, there might not."****
>       - recipes-bsp/formfactor shouldn't also have another formfactor
>       directory, should it?  Or is the "files" directory in 1.4 replaced with
>       another formfactor-named directory?  Also, <name> should be <machine> again.
>       ****
>       - What's everything from recipes-core down?  I can buy
>       recipes-kernel being in a bsp, but are any other directories really
>       necessary?****
>
>  Kind regards,****
>
> ** **
>
> Jerrod****
>
> ** **
>
> On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M <
> scott.m.rifenbark@intel.com> wrote:****
>
> Hi,
>
> This next illustration attempting to dive deeper in the YP Development
> Process takes the remaining left-side input from that figure in the Quick
> Start (metadata, Machine, and Policy).  Note that when the original figure
> was created that appears in the QS, the layer stuff had not yet been
> established.  This figure I am attaching is rough.  I am unsure as to the
> contents of these layers.  Right now it is detailed but with generic names.
>  The idea is that individual layers are preferred to do things such as
> provide software, configure policy, and configure machines.  I am including
> some notes at the bottom of the figure that would not be part of the figure
> but might help to get across what I am trying to accomplish here.
>
> Any suggestions and feedback is really appreciated.
>
> Thanks,
> Scott
>
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto****
>
> ** **
>

[-- Attachment #2: Type: text/html, Size: 7600 bytes --]

Re: Layer input

[Rifenbark, Scott M]

[-- Attachment #1.1: Type: text/plain, Size: 5243 bytes --]

Jerrod,

I looked at the various folder names in the meta-intel layer, which has many BSP layers.  After looking at these, you are right in that <name> could probably better described a <recipe> since all the *.bb and *.bbappend files have as a root name the recipe.  So I changed them.  The specifically-named recipes-* directories follow the BSP layout guidelines described in the BSP manual.  Granted, not all BSP layers have them all.  One option is to just show them in the figure as recipes-* and then describe them in the supporting text as possibly being recipes-core, recipes-kernel, recipes-graphics, and recipes-bsp.  You can run yocto-layer after you source oe-init-build-env script.  The script itself lives in poky/scripts.

Finally, bblayers.conf appears as part of the user configuration figure.  You have a valid point about bblayers.conf though because it does directly affect BitBake finding the layers, which are the point of this particular diagram.  I altered the figure to include an abbreviated version of the "Build Directory" so that it just shows conf/bblayers.conf.  The supporting text around the figure can describe the relationship and also note that a different figure breaks out the user configuration input in more detail.

Scott

From: Jerrod Peach [mailto:peachj@lexmark.com]
Sent: Thursday, June 27, 2013 5:56 AM
To: Rifenbark, Scott M
Cc: Bruce Ashfield; yocto@yoctoproject.org; Paul Eggleton
Subject: Re: [yocto] Layer input

Scott,

Getting closer to what I was thinking, but I still have a couple questions, primarily regarding the BSP layer.

  *   There are still a few references to <name>.  Shouldn't those also be <recipe>?
  *   I'm still confused by the presence of all the specifically-named recipes-* directories.  I tried running yocto-layer and I didn't get any of those present.  I couldn't find the bsp-layer tool, but I'll grant I didn't search really hard.  (I only checked out master of poky and searched around a bit.)  What's making you want to put them all in this diagram?
Also, it strikes me that bblayers.conf needs to show up in this diagram somewhere, I think, since it controls what layers bitbake sees.

Kind regards,

Jerrod

On Thu, Jun 27, 2013 at 3:41 AM, Rifenbark, Scott M <scott.m.rifenbark@intel.com<mailto:scott.m.rifenbark@intel.com>> wrote:
Hi,

I have tweaked this figure some based on Bruce and Jerrod's input.  To help me figure out some of the basics, I ran the yocto-layer and bsp-layer scripts to create a general and BSP layer, respectively.  Please look over the contents of these layers and comment.  General comments on the whole concept of how I am presenting the layers are welcome along with any other observations.

Thanks,
Scott

From: Jerrod Peach [mailto:peachj@lexmark.com<mailto:peachj@lexmark.com>]
Sent: Tuesday, June 25, 2013 11:07 AM

To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>; Paul Eggleton
Subject: Re: [yocto] Layer input

Scott,

  *   Distro Layer

     *   I'm unclear on what <name> is.  Is that supposed to be <distro>?  <recipe>?  It probably shouldn't just be <name>, should it?

  *   Software Layer

     *   Should COPYING.MIT just be COPYING to be more generically applicable?
     *   conf/<layer_name>.conf should be just layer.conf, right?

  *   BSP Layer

     *   COPYING.MIT file again.
     *   machine/<name>.conf should probably be machine/<machine*>.conf.  You can probably drop the non-asterisk version, since an asterisk implies, "There might be more stuff, there might not."
     *   recipes-bsp/formfactor shouldn't also have another formfactor directory, should it?  Or is the "files" directory in 1.4 replaced with another formfactor-named directory?  Also, <name> should be <machine> again.
     *   What's everything from recipes-core down?  I can buy recipes-kernel being in a bsp, but are any other directories really necessary?
Kind regards,

Jerrod

On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M <scott.m.rifenbark@intel.com<mailto:scott.m.rifenbark@intel.com>> wrote:
Hi,

This next illustration attempting to dive deeper in the YP Development Process takes the remaining left-side input from that figure in the Quick Start (metadata, Machine, and Policy).  Note that when the original figure was created that appears in the QS, the layer stuff had not yet been established.  This figure I am attaching is rough.  I am unsure as to the contents of these layers.  Right now it is detailed but with generic names.  The idea is that individual layers are preferred to do things such as provide software, configure policy, and configure machines.  I am including some notes at the bottom of the figure that would not be part of the figure but might help to get across what I am trying to accomplish here.

Any suggestions and feedback is really appreciated.

Thanks,
Scott

Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702<tel:503.712.2702>
503.341.0418<tel:503.341.0418> (cell)



_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #1.2: Type: text/html, Size: 17722 bytes --]

[-- Attachment #2: layer-input.png --]
[-- Type: image/png, Size: 80436 bytes --]

Re: Layer input

[Philip Balister]

On 06/27/2013 03:41 AM, Rifenbark, Scott M wrote:
> Hi,
> 
> I have tweaked this figure some based on Bruce and Jerrod's input.  To help me figure out some of the basics, I ran the yocto-layer and bsp-layer scripts to create a general and BSP layer, respectively.  Please look over the contents of these layers and comment.  General comments on the whole concept of how I am presenting the layers are welcome along with any other observations.

I'm confused by the last line of test about Yocto project layers and
layers exclusive to oe-core. All layers should play together, so the
concept of layers exclusive to oe-core does not make sense to me.

Philip

> 
> Thanks,
> Scott
> 
> From: Jerrod Peach [mailto:peachj@lexmark.com]
> Sent: Tuesday, June 25, 2013 11:07 AM
> To: Rifenbark, Scott M
> Cc: yocto@yoctoproject.org; Paul Eggleton
> Subject: Re: [yocto] Layer input
> 
> Scott,
> 
>   *   Distro Layer
> 
>      *   I'm unclear on what <name> is.  Is that supposed to be <distro>?  <recipe>?  It probably shouldn't just be <name>, should it?
> 
>   *   Software Layer
> 
>      *   Should COPYING.MIT just be COPYING to be more generically applicable?
>      *   conf/<layer_name>.conf should be just layer.conf, right?
> 
>   *   BSP Layer
> 
>      *   COPYING.MIT file again.
>      *   machine/<name>.conf should probably be machine/<machine*>.conf.  You can probably drop the non-asterisk version, since an asterisk implies, "There might be more stuff, there might not."
>      *   recipes-bsp/formfactor shouldn't also have another formfactor directory, should it?  Or is the "files" directory in 1.4 replaced with another formfactor-named directory?  Also, <name> should be <machine> again.
>      *   What's everything from recipes-core down?  I can buy recipes-kernel being in a bsp, but are any other directories really necessary?
> Kind regards,
> 
> Jerrod
> 
> On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M <scott.m.rifenbark@intel.com<mailto:scott.m.rifenbark@intel.com>> wrote:
> Hi,
> 
> This next illustration attempting to dive deeper in the YP Development Process takes the remaining left-side input from that figure in the Quick Start (metadata, Machine, and Policy).  Note that when the original figure was created that appears in the QS, the layer stuff had not yet been established.  This figure I am attaching is rough.  I am unsure as to the contents of these layers.  Right now it is detailed but with generic names.  The idea is that individual layers are preferred to do things such as provide software, configure policy, and configure machines.  I am including some notes at the bottom of the figure that would not be part of the figure but might help to get across what I am trying to accomplish here.
> 
> Any suggestions and feedback is really appreciated.
> 
> Thanks,
> Scott
> 
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702<tel:503.712.2702>
> 503.341.0418<tel:503.341.0418> (cell)
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

Re: Layer input

[Rifenbark, Scott M]

Hi Philip, 

They do all play together.  Using the phrasing "exclusive to" was probably not the best choice of words here.  Initially, my understanding was that the layers in the Yocto Metadata Layers section of the YP Source Repositories was a subset of the layers listed in the OpenEmbedded metadata index.  But, after looking at them again, I discovered that not all layers found in the Yocto list actually appear in the OE list. So, I need some more clarification on just exactly what each of these areas contain.  I was told that the YP area is open to any layer that is related to YP and that some layers in there are provided and maintained by people outside of the YP team (e.g. meta-ti, meta-mentor, etc.).  Some of these do also appear in the OE index.  However, there are some in the YP area that do not appear in the OE list (e.g. poky-extras, meta-baryon, meta-dlna, etc).

So, I need some more clarification on exactly how these two indexes relate.  Once I get that I will update that text and the explanation that goes with the figure that ultimately finds its way into the documentation will me accurate.

Also, I think it would be useful to actually include a layer block in the final figure that represented the OE index as well.  Right now, that is missing.  So that will be added as well.

Thanks for the input Philip.
 

>-----Original Message-----
>From: Philip Balister [mailto:philip@balister.org]
>Sent: Thursday, June 27, 2013 2:02 PM
>To: Rifenbark, Scott M
>Cc: Jerrod Peach; Bruce Ashfield; yocto@yoctoproject.org; Paul Eggleton
>Subject: Re: [yocto] Layer input
>
>On 06/27/2013 03:41 AM, Rifenbark, Scott M wrote:
>> Hi,
>>
>> I have tweaked this figure some based on Bruce and Jerrod's input.  To
>help me figure out some of the basics, I ran the yocto-layer and bsp-
>layer scripts to create a general and BSP layer, respectively.  Please
>look over the contents of these layers and comment.  General comments on
>the whole concept of how I am presenting the layers are welcome along
>with any other observations.
>
>I'm confused by the last line of test about Yocto project layers and
>layers exclusive to oe-core. All layers should play together, so the
>concept of layers exclusive to oe-core does not make sense to me.
>
>Philip
>
>>
>> Thanks,
>> Scott
>>
>> From: Jerrod Peach [mailto:peachj@lexmark.com]
>> Sent: Tuesday, June 25, 2013 11:07 AM
>> To: Rifenbark, Scott M
>> Cc: yocto@yoctoproject.org; Paul Eggleton
>> Subject: Re: [yocto] Layer input
>>
>> Scott,
>>
>>   *   Distro Layer
>>
>>      *   I'm unclear on what <name> is.  Is that supposed to be
><distro>?  <recipe>?  It probably shouldn't just be <name>, should it?
>>
>>   *   Software Layer
>>
>>      *   Should COPYING.MIT just be COPYING to be more generically
>applicable?
>>      *   conf/<layer_name>.conf should be just layer.conf, right?
>>
>>   *   BSP Layer
>>
>>      *   COPYING.MIT file again.
>>      *   machine/<name>.conf should probably be
>machine/<machine*>.conf.  You can probably drop the non-asterisk
>version, since an asterisk implies, "There might be more stuff, there
>might not."
>>      *   recipes-bsp/formfactor shouldn't also have another formfactor
>directory, should it?  Or is the "files" directory in 1.4 replaced with
>another formfactor-named directory?  Also, <name> should be <machine>
>again.
>>      *   What's everything from recipes-core down?  I can buy recipes-
>kernel being in a bsp, but are any other directories really necessary?
>> Kind regards,
>>
>> Jerrod
>>
>> On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M
><scott.m.rifenbark@intel.com<mailto:scott.m.rifenbark@intel.com>> wrote:
>> Hi,
>>
>> This next illustration attempting to dive deeper in the YP Development
>Process takes the remaining left-side input from that figure in the
>Quick Start (metadata, Machine, and Policy).  Note that when the
>original figure was created that appears in the QS, the layer stuff had
>not yet been established.  This figure I am attaching is rough.  I am
>unsure as to the contents of these layers.  Right now it is detailed but
>with generic names.  The idea is that individual layers are preferred to
>do things such as provide software, configure policy, and configure
>machines.  I am including some notes at the bottom of the figure that
>would not be part of the figure but might help to get across what I am
>trying to accomplish here.
>>
>> Any suggestions and feedback is really appreciated.
>>
>> Thanks,
>> Scott
>>
>> Scott Rifenbark
>> Intel Corporation
>> Yocto Project Documentation
>> 503.712.2702<tel:503.712.2702>
>> 503.341.0418<tel:503.341.0418> (cell)
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>

Re: Layer input

[Rifenbark, Scott M]

[-- Attachment #1: Type: text/plain, Size: 6866 bytes --]

Hi, 

Here is the story on the relationship between the YP Metadata Layers as listed in the YP Source Repositories and the OpenEmbedded Metadata Index.  Functionally, the YP layers are a subset of the OE layers.  However, the YP layers are not a true subset of the OE layers.  The YP layers have many layers that do not appear in the OE index for one reason or another.  Some YP layers are deprecated (e.g. meta-dlna), some should not be there and are being actively worked for removal or movement (e.g. poky-extras and yocto-docs).  Some are experimental layers (e.g. any layer that starts with "experimental"). And one is a contribution layer used by the Yocto Team (e.g. meta-intel-contrib).

The text I create supporting this "layer" figure will describe this relationship so people will know from where existing layers originate.

I am deciding against adding more boxes to the already large figure and am going to retain just the large "Layers" box.  It will have supporting text that describes how a layer could be user-created, could originate from the YP Metadata Layers list, or could originate from the OpenEmbedded Metadata Index of layers. 

Scott

>-----Original Message-----
>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Rifenbark, Scott M
>Sent: Thursday, June 27, 2013 11:14 PM
>To: Philip Balister
>Cc: Paul Eggleton; yocto@yoctoproject.org
>Subject: Re: [yocto] Layer input
>
>Hi Philip,
>
>They do all play together.  Using the phrasing "exclusive to" was
>probably not the best choice of words here.  Initially, my understanding
>was that the layers in the Yocto Metadata Layers section of the YP
>Source Repositories was a subset of the layers listed in the
>OpenEmbedded metadata index.  But, after looking at them again, I
>discovered that not all layers found in the Yocto list actually appear
>in the OE list. So, I need some more clarification on just exactly what
>each of these areas contain.  I was told that the YP area is open to any
>layer that is related to YP and that some layers in there are provided
>and maintained by people outside of the YP team (e.g. meta-ti, meta-
>mentor, etc.).  Some of these do also appear in the OE index.  However,
>there are some in the YP area that do not appear in the OE list (e.g.
>poky-extras, meta-baryon, meta-dlna, etc).
>
>So, I need some more clarification on exactly how these two indexes
>relate.  Once I get that I will update that text and the explanation
>that goes with the figure that ultimately finds its way into the
>documentation will me accurate.
>
>Also, I think it would be useful to actually include a layer block in
>the final figure that represented the OE index as well.  Right now, that
>is missing.  So that will be added as well.
>
>Thanks for the input Philip.
>
>
>>-----Original Message-----
>>From: Philip Balister [mailto:philip@balister.org]
>>Sent: Thursday, June 27, 2013 2:02 PM
>>To: Rifenbark, Scott M
>>Cc: Jerrod Peach; Bruce Ashfield; yocto@yoctoproject.org; Paul Eggleton
>>Subject: Re: [yocto] Layer input
>>
>>On 06/27/2013 03:41 AM, Rifenbark, Scott M wrote:
>>> Hi,
>>>
>>> I have tweaked this figure some based on Bruce and Jerrod's input.
>To
>>help me figure out some of the basics, I ran the yocto-layer and bsp-
>>layer scripts to create a general and BSP layer, respectively.  Please
>>look over the contents of these layers and comment.  General comments
>on
>>the whole concept of how I am presenting the layers are welcome along
>>with any other observations.
>>
>>I'm confused by the last line of test about Yocto project layers and
>>layers exclusive to oe-core. All layers should play together, so the
>>concept of layers exclusive to oe-core does not make sense to me.
>>
>>Philip
>>
>>>
>>> Thanks,
>>> Scott
>>>
>>> From: Jerrod Peach [mailto:peachj@lexmark.com]
>>> Sent: Tuesday, June 25, 2013 11:07 AM
>>> To: Rifenbark, Scott M
>>> Cc: yocto@yoctoproject.org; Paul Eggleton
>>> Subject: Re: [yocto] Layer input
>>>
>>> Scott,
>>>
>>>   *   Distro Layer
>>>
>>>      *   I'm unclear on what <name> is.  Is that supposed to be
>><distro>?  <recipe>?  It probably shouldn't just be <name>, should it?
>>>
>>>   *   Software Layer
>>>
>>>      *   Should COPYING.MIT just be COPYING to be more generically
>>applicable?
>>>      *   conf/<layer_name>.conf should be just layer.conf, right?
>>>
>>>   *   BSP Layer
>>>
>>>      *   COPYING.MIT file again.
>>>      *   machine/<name>.conf should probably be
>>machine/<machine*>.conf.  You can probably drop the non-asterisk
>>version, since an asterisk implies, "There might be more stuff, there
>>might not."
>>>      *   recipes-bsp/formfactor shouldn't also have another
>formfactor
>>directory, should it?  Or is the "files" directory in 1.4 replaced with
>>another formfactor-named directory?  Also, <name> should be <machine>
>>again.
>>>      *   What's everything from recipes-core down?  I can buy
>recipes-
>>kernel being in a bsp, but are any other directories really necessary?
>>> Kind regards,
>>>
>>> Jerrod
>>>
>>> On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M
>><scott.m.rifenbark@intel.com<mailto:scott.m.rifenbark@intel.com>>
>wrote:
>>> Hi,
>>>
>>> This next illustration attempting to dive deeper in the YP
>Development
>>Process takes the remaining left-side input from that figure in the
>>Quick Start (metadata, Machine, and Policy).  Note that when the
>>original figure was created that appears in the QS, the layer stuff had
>>not yet been established.  This figure I am attaching is rough.  I am
>>unsure as to the contents of these layers.  Right now it is detailed
>but
>>with generic names.  The idea is that individual layers are preferred
>to
>>do things such as provide software, configure policy, and configure
>>machines.  I am including some notes at the bottom of the figure that
>>would not be part of the figure but might help to get across what I am
>>trying to accomplish here.
>>>
>>> Any suggestions and feedback is really appreciated.
>>>
>>> Thanks,
>>> Scott
>>>
>>> Scott Rifenbark
>>> Intel Corporation
>>> Yocto Project Documentation
>>> 503.712.2702<tel:503.712.2702>
>>> 503.341.0418<tel:503.341.0418> (cell)
>>>
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: layer-input.png --]
[-- Type: image/png, Size: 88309 bytes --]

Re: Layer input

[Paul Eggleton]

On Friday 28 June 2013 10:50:01 Rifenbark, Scott M wrote:
> Here is the story on the relationship between the YP Metadata Layers as
> listed in the YP Source Repositories and the OpenEmbedded Metadata Index. 
> Functionally, the YP layers are a subset of the OE layers.  However, the YP
> layers are not a true subset of the OE layers.  The YP layers have many
> layers that do not appear in the OE index for one reason or another.  

I wouldn't say many, there are just a few exceptions. The way to look at it is 
the OE layer index is a central directory of layers that should be advertised, 
whereas what you see on git.yoctoproject.org is simply a listing of all of the 
repositories on git.yoctoproject.org, of which a subset are layers and a 
subset of those are current, maintained and should be promoted for people to 
use (and all of the latter should be in the OE layer index).

> Some YP layers are deprecated (e.g. meta-dlna), some should not be there and
> are being actively worked for removal or movement (e.g. poky-extras and
> yocto-docs).  Some are experimental layers (e.g. any layer that starts with
> "experimental"). And one is a contribution layer used by the Yocto Team
> (e.g. meta-intel-contrib).

FWIW, like the other contrib repos I think the latter is open access, anyone 
can get commit rights to facilitate sending pull requests.

> The text I create supporting this "layer" figure will describe this
> relationship so people will know from where existing layers originate.
> 
> I am deciding against adding more boxes to the already large figure and am
> going to retain just the large "Layers" box.  It will have supporting text
> that describes how a layer could be user-created, could originate from the
> YP Metadata Layers list, or could originate from the OpenEmbedded Metadata
> Index of layers.

Looking over the most recent version of this figure I'd suggest:

* conf/bblayers.conf in the distro layer shouldn't be there.

* The recipes-kernel in the distro layer should be dropped. I know we include 
linux-libc-headers-yocto in Poky but that is not typical.

* I think maybe like the other diagrams it would help if there were a different 
emphasis for items that are mandatory and items that are optional (e.g. 
bolding mandatory items or greying out optional items).

* Replace <mod_name> with <recipe>

* Replace <machine*> with <machine>

Cheers,
Paul



-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Layer input

[Rifenbark, Scott M]

[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]

For Paul.

>-----Original Message-----
>From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
>Sent: Friday, June 28, 2013 4:08 AM
>To: Rifenbark, Scott M
>Cc: Philip Balister; yocto@yoctoproject.org
>Subject: Re: [yocto] Layer input
>
>On Friday 28 June 2013 10:50:01 Rifenbark, Scott M wrote:
>> Here is the story on the relationship between the YP Metadata Layers
>as
>> listed in the YP Source Repositories and the OpenEmbedded Metadata
>Index.
>> Functionally, the YP layers are a subset of the OE layers.  However,
>the YP
>> layers are not a true subset of the OE layers.  The YP layers have
>many
>> layers that do not appear in the OE index for one reason or another.
>
>I wouldn't say many, there are just a few exceptions. The way to look at
>it is
>the OE layer index is a central directory of layers that should be
>advertised,
>whereas what you see on git.yoctoproject.org is simply a listing of all
>of the
>repositories on git.yoctoproject.org, of which a subset are layers and a
>subset of those are current, maintained and should be promoted for
>people to
>use (and all of the latter should be in the OE layer index).

I count eight meta-* layers in the YP repositories that don't exist in the OE area.  I understand what you are saying though and I can word it that way to dampen the existence of the "many" differences :)

>
>> Some YP layers are deprecated (e.g. meta-dlna), some should not be
>there and
>> are being actively worked for removal or movement (e.g. poky-extras
>and
>> yocto-docs).  Some are experimental layers (e.g. any layer that starts
>with
>> "experimental"). And one is a contribution layer used by the Yocto
>Team
>> (e.g. meta-intel-contrib).
>
>FWIW, like the other contrib repos I think the latter is open access,
>anyone
>can get commit rights to facilitate sending pull requests.

I can explain the contrib areas as you suggest.

>
>> The text I create supporting this "layer" figure will describe this
>> relationship so people will know from where existing layers originate.
>>
>> I am deciding against adding more boxes to the already large figure
>and am
>> going to retain just the large "Layers" box.  It will have supporting
>text
>> that describes how a layer could be user-created, could originate from
>the
>> YP Metadata Layers list, or could originate from the OpenEmbedded
>Metadata
>> Index of layers.
>
>Looking over the most recent version of this figure I'd suggest:
>
>* conf/bblayers.conf in the distro layer shouldn't be there.

Ok - I removed this.

>
>* The recipes-kernel in the distro layer should be dropped. I know we
>include
>linux-libc-headers-yocto in Poky but that is not typical.

Ok - I removed it.

>
>* I think maybe like the other diagrams it would help if there were a
>different
>emphasis for items that are mandatory and items that are optional (e.g.
>bolding mandatory items or greying out optional items).

I don't know what is mandatory and what is not.  Can you provide some guidance here? Thanks.

>
>* Replace <mod_name> with <recipe>
>
>* Replace <machine*> with <machine>

Ok - I fixed the above two items.

>
>Cheers,
>Paul
>
>
>
>--
>
>Paul Eggleton
>Intel Open Source Technology Centre

[-- Attachment #2: layer-input.png --]
[-- Type: image/png, Size: 86284 bytes --]

Re: Layer input

[Khem Raj]

On Jun 28, 2013, at 4:22 AM, "Rifenbark, Scott M" <scott.m.rifenbark@intel.com> wrote:

> I count eight meta-* layers in the YP repositories that don't exist in the OE area.  I understand what you are saying though and I can word it that way to dampen the existence of the "many" differences :)
> 

hmm may be they should be added to layer index. at least the ones which are still maintained.

>> 
>>> Some YP layers are deprecated (e.g. meta-dlna), some should not be
>> there and
>>> are being actively worked for removal or movement (e.g. poky-extras
>> and
>>> yocto-docs).  Some are experimental layers (e.g. any layer that starts
>> with
>>> "experimental"). And one is a contribution layer used by the Yocto
>> Team
>>> (e.g. meta-intel-contrib).
>> 
>> FWIW, like the other contrib repos I think the latter is open access,
>> anyone
>> can get commit rights to facilitate sending pull requests.
> 

Re: Layer input

[Paul Eggleton]

On Friday 28 June 2013 14:36:48 Khem Raj wrote:
> On Jun 28, 2013, at 4:22 AM, "Rifenbark, Scott M"
> <scott.m.rifenbark@intel.com> wrote:
> > I count eight meta-* layers in the YP repositories that don't exist in the
> > OE area.  I understand what you are saying though and I can word it that
> > way to dampen the existence of the "many" differences :)
>
> hmm may be they should be added to layer index. at least the ones which are
> still maintained.

This is down to me, I've been keeping the layer index up-to-date for the 
layers on yoctoproject.org. Listing the ones that aren't there, with comments 
as to why not:

experimental/meta-darwin
    - ancient, unmaintained, no conf/layer.conf
experimental/meta-m2
    - ancient, unmaintained
experimental/meta-maemo
    - ancient, unmaintained, no conf/layer.conf
experimental/meta-trusted
    - not actively maintained
experimental/meta-x32       
    - ancient, we should probably just delete this
meta-dlna
    - replaced by collaboration with meta-guacamayo
meta-extras
    - not usable as a layer, most recipes unbuildable; I'm slowly whittling it
      down as bits of it reappear in OE layers until one day hopefully it'll
      become empty
meta-intel-contrib
    - contrib repo for meta-intel
meta-jarvis
    - joke layer
meta-meson
    - (probably could add)
meta-meson-bsp
    - (probably could add)
meta-minnow
    - (was waiting for hardware availability)
meta-yocto-kernel-extras
    - now submitted to the layer index
meta-zynq
    - status not entirely clear, but seems to have been superseded?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Layer input

[Bruce Ashfield]

On 13-07-08 11:16 AM, Paul Eggleton wrote:
> On Friday 28 June 2013 14:36:48 Khem Raj wrote:
>> On Jun 28, 2013, at 4:22 AM, "Rifenbark, Scott M"
>> <scott.m.rifenbark@intel.com> wrote:
>>> I count eight meta-* layers in the YP repositories that don't exist in the
>>> OE area.  I understand what you are saying though and I can word it that
>>> way to dampen the existence of the "many" differences :)
>>
>> hmm may be they should be added to layer index. at least the ones which are
>> still maintained.
>
> This is down to me, I've been keeping the layer index up-to-date for the
> layers on yoctoproject.org. Listing the ones that aren't there, with comments
> as to why not:
>
> experimental/meta-darwin
>      - ancient, unmaintained, no conf/layer.conf
> experimental/meta-m2
>      - ancient, unmaintained
> experimental/meta-maemo
>      - ancient, unmaintained, no conf/layer.conf
> experimental/meta-trusted
>      - not actively maintained
> experimental/meta-x32
>      - ancient, we should probably just delete this
> meta-dlna
>      - replaced by collaboration with meta-guacamayo
> meta-extras
>      - not usable as a layer, most recipes unbuildable; I'm slowly whittling it
>        down as bits of it reappear in OE layers until one day hopefully it'll
>        become empty
> meta-intel-contrib
>      - contrib repo for meta-intel
> meta-jarvis
>      - joke layer
> meta-meson
>      - (probably could add)
> meta-meson-bsp
>      - (probably could add)
> meta-minnow
>      - (was waiting for hardware availability)
> meta-yocto-kernel-extras
>      - now submitted to the layer index
> meta-zynq
>      - status not entirely clear, but seems to have been superseded?

Superseded. The xilinx guys have linux-yocto support in hand in their
layers no, so we can mark this as dead.

Bruce

>
> Cheers,
> Paul
>