* BSP Packagegroup @ 2015-07-09 14:56 Daiane Angolini 2015-07-09 16:29 ` Ann Thornton 0 siblings, 1 reply; 6+ messages in thread From: Daiane Angolini @ 2015-07-09 14:56 UTC (permalink / raw) To: meta-freescale@yoctoproject.org For me, packagegroup is only a set of packages wrapped together to make my life easier. Should BSP provide packagegroups to ease the addition (and removal) of set o BSP packages, or their “functional” dependency. For example an application such as aplay is needed to stress the audio functionality, even though there is no dependency from alsa driver from kernel with alsa-utils. Should BSP provide packagegroups? I think offering packagegroup options to enable BSP pieces may really ease the BSP usage, however I main point here is how far should BSP go. What is the limit between a BSP packagegroup and a "demo" packagegroup (as we does in meta-fsl-demos)? Thinking about a package group to provide BSP packages related with VPU, in my opinion it should have: * VPU firmware * VPU lib In case I’m using gstreamer, I would like a packagegroup like: * VPU firmware * VPU lib * gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin) In case I’m using gstreamer with kernel mainline: * VPU firmware * gstreamer Should mp3 encoder (such as lame) be part of a BSP packagegroup? And in GPU case? Would DEPENDS and PROVIDES be enough to include needed packages? Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP packagegroup even though there is no special hardware acceleration provided by meta-fsl-arm for bluetooth? Daiane ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BSP Packagegroup 2015-07-09 14:56 BSP Packagegroup Daiane Angolini @ 2015-07-09 16:29 ` Ann Thornton 2015-07-11 14:24 ` Daiane Angolini 0 siblings, 1 reply; 6+ messages in thread From: Ann Thornton @ 2015-07-09 16:29 UTC (permalink / raw) To: meta-freescale [-- Attachment #1: Type: text/plain, Size: 2095 bytes --] For packagegroup divisions, how about graphics multimedia networking tools (probably others I haven't thought of) Each of those groups might be further divided into minimal, core, demos, extended as needed. Each packagegroup could check DISTRO-FEATURES, etc so that they would be as generic as possible. Then recipes could include the level of detail desired and they would work across product lines. Ann Thornton On 7/9/2015 9:56 AM, Daiane Angolini wrote: > For me, packagegroup is only a set of packages wrapped together to > make my life easier. > > Should BSP provide packagegroups to ease the addition (and removal) of > set o BSP packages, or their “functional” dependency. For example an > application such as aplay is needed to stress the audio functionality, > even though there is no dependency from alsa driver from kernel with > alsa-utils. Should BSP provide packagegroups? > > I think offering packagegroup options to enable BSP pieces may really > ease the BSP usage, however I main point here is how far should BSP > go. What is the limit between a BSP packagegroup and a "demo" > packagegroup (as we does in meta-fsl-demos)? > > Thinking about a package group to provide BSP packages related with > VPU, in my opinion it should have: > > * VPU firmware > * VPU lib > > In case I’m using gstreamer, I would like a packagegroup like: > > * VPU firmware > * VPU lib > * gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin) > > In case I’m using gstreamer with kernel mainline: > > * VPU firmware > * gstreamer > > > Should mp3 encoder (such as lame) be part of a BSP packagegroup? And > in GPU case? Would DEPENDS and PROVIDES be enough to include needed > packages? > > Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP > packagegroup even though there is no special hardware acceleration > provided by meta-fsl-arm for bluetooth? > > > Daiane -- Ann Thornton /Microcontrollers Software and Applications Freescale Semiconductors email: Ann.Thornton@freescale.com/ [-- Attachment #2: Type: text/html, Size: 2777 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BSP Packagegroup 2015-07-09 16:29 ` Ann Thornton @ 2015-07-11 14:24 ` Daiane Angolini 2015-07-15 16:21 ` Ann Thornton 0 siblings, 1 reply; 6+ messages in thread From: Daiane Angolini @ 2015-07-11 14:24 UTC (permalink / raw) To: Ann Thornton; +Cc: meta-freescale@yoctoproject.org On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton <Ann.Thornton@freescale.com> wrote: > > For packagegroup divisions, how about > graphics > multimedia > networking > tools > (probably others I haven't thought of) When we think about a set of packagegroups intended to give users a set of useful packages or an example on how to group applications more is more. As much as possible is good enough. (meta-fsl-demos) However, when you think about a BSP packagegroup, less is more. As less as possible, as much closer to only critical packages, the minimal set, is the optimal packagegroup. (meta-fsl-arm) Do we need BSP packagegroups? In case we do, I cannot see the need of a BSP packagegroup for graphic (GPU) or tools. I would accept "tools" to be split into other sets like "audio", but definitively not "tools". In fact, I can only see the need of a VPU and a CAN package groups. Maybe audio. But I'm trying to stress the BSP packagegroup idea here, something I'm not completely convinced of. Daiane > > Each of those groups might be further divided into minimal, core, demos, > extended as needed. > > Each packagegroup could check DISTRO-FEATURES, etc so that they would be as > generic as possible. > > Then recipes could include the level of detail desired and they would work > across product lines. > > Ann Thornton > > > On 7/9/2015 9:56 AM, Daiane Angolini wrote: > > For me, packagegroup is only a set of packages wrapped together to > make my life easier. > > Should BSP provide packagegroups to ease the addition (and removal) of > set o BSP packages, or their “functional” dependency. For example an > application such as aplay is needed to stress the audio functionality, > even though there is no dependency from alsa driver from kernel with > alsa-utils. Should BSP provide packagegroups? > > I think offering packagegroup options to enable BSP pieces may really > ease the BSP usage, however I main point here is how far should BSP > go. What is the limit between a BSP packagegroup and a "demo" > packagegroup (as we does in meta-fsl-demos)? > > Thinking about a package group to provide BSP packages related with > VPU, in my opinion it should have: > > * VPU firmware > * VPU lib > > In case I’m using gstreamer, I would like a packagegroup like: > > * VPU firmware > * VPU lib > * gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin) > > In case I’m using gstreamer with kernel mainline: > > * VPU firmware > * gstreamer > > > Should mp3 encoder (such as lame) be part of a BSP packagegroup? And > in GPU case? Would DEPENDS and PROVIDES be enough to include needed > packages? > > Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP > packagegroup even though there is no special hardware acceleration > provided by meta-fsl-arm for bluetooth? > > > Daiane > > > > -- > Ann Thornton > > Microcontrollers Software and Applications > Freescale Semiconductors > email: Ann.Thornton@freescale.com > > -- > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BSP Packagegroup 2015-07-11 14:24 ` Daiane Angolini @ 2015-07-15 16:21 ` Ann Thornton 2015-07-15 16:29 ` Daiane Angolini 0 siblings, 1 reply; 6+ messages in thread From: Ann Thornton @ 2015-07-15 16:21 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 4088 bytes --] I am thinking of packagegroups as a way to make life easier. Graphics in particular is complicated, with some things working in one place and not another. Graphics packagegroups can handle a lot of that so a common image recipe can easily work in multiple environments and new recipes can be created more easily without having to know every detail. Having different levels allows an easy way to choose how much to include in a particular image. Packagegroups are not specific to BSP or SDK or whatever. They can be used wherever desired. Ann On 7/11/2015 9:24 AM, Daiane Angolini wrote: > On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton <Ann.Thornton@freescale.com> wrote: >> For packagegroup divisions, how about >> graphics >> multimedia >> networking >> tools >> (probably others I haven't thought of) > When we think about a set of packagegroups intended to give users a > set of useful packages or an example on how to group applications more > is more. As much as possible is good enough. (meta-fsl-demos) > > However, when you think about a BSP packagegroup, less is more. As > less as possible, as much closer to only critical packages, the > minimal set, is the optimal packagegroup. (meta-fsl-arm) > > Do we need BSP packagegroups? > > In case we do, I cannot see the need of a BSP packagegroup for graphic > (GPU) or tools. > > I would accept "tools" to be split into other sets like "audio", but > definitively not "tools". > > In fact, I can only see the need of a VPU and a CAN package groups. > Maybe audio. But I'm trying to stress the BSP packagegroup idea here, > something I'm not completely convinced of. > > > Daiane >> Each of those groups might be further divided into minimal, core, demos, >> extended as needed. >> >> Each packagegroup could check DISTRO-FEATURES, etc so that they would be as >> generic as possible. >> >> Then recipes could include the level of detail desired and they would work >> across product lines. >> >> Ann Thornton >> >> >> On 7/9/2015 9:56 AM, Daiane Angolini wrote: >> >> For me, packagegroup is only a set of packages wrapped together to >> make my life easier. >> >> Should BSP provide packagegroups to ease the addition (and removal) of >> set o BSP packages, or their “functional” dependency. For example an >> application such as aplay is needed to stress the audio functionality, >> even though there is no dependency from alsa driver from kernel with >> alsa-utils. Should BSP provide packagegroups? >> >> I think offering packagegroup options to enable BSP pieces may really >> ease the BSP usage, however I main point here is how far should BSP >> go. What is the limit between a BSP packagegroup and a "demo" >> packagegroup (as we does in meta-fsl-demos)? >> >> Thinking about a package group to provide BSP packages related with >> VPU, in my opinion it should have: >> >> * VPU firmware >> * VPU lib >> >> In case I’m using gstreamer, I would like a packagegroup like: >> >> * VPU firmware >> * VPU lib >> * gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin) >> >> In case I’m using gstreamer with kernel mainline: >> >> * VPU firmware >> * gstreamer >> >> >> Should mp3 encoder (such as lame) be part of a BSP packagegroup? And >> in GPU case? Would DEPENDS and PROVIDES be enough to include needed >> packages? >> >> Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP >> packagegroup even though there is no special hardware acceleration >> provided by meta-fsl-arm for bluetooth? >> >> >> Daiane >> >> >> >> -- >> Ann Thornton >> >> Microcontrollers Software and Applications >> Freescale Semiconductors >> email: Ann.Thornton@freescale.com >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale >> -- Ann Thornton /Microcontrollers Software and Applications Freescale Semiconductors email: Ann.Thornton@freescale.com/ [-- Attachment #2: Type: text/html, Size: 5063 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BSP Packagegroup 2015-07-15 16:21 ` Ann Thornton @ 2015-07-15 16:29 ` Daiane Angolini 2015-07-15 16:49 ` Otavio Salvador 0 siblings, 1 reply; 6+ messages in thread From: Daiane Angolini @ 2015-07-15 16:29 UTC (permalink / raw) To: Ann Thornton; +Cc: meta-freescale@yoctoproject.org On Wed, Jul 15, 2015 at 1:21 PM, Ann Thornton <Ann.Thornton@freescale.com> wrote: > > I am thinking of packagegroups as a way to make life easier. Graphics in > particular is complicated, with some things working in one place and not > another. Graphics packagegroups can handle a lot of that so a common image > recipe can easily work in multiple environments and new recipes can be > created more easily without having to know every detail. Having different > levels allows an easy way to choose how much to include in a particular > image. Packagegroups are not specific to BSP or SDK or whatever. They can > be used wherever desired. I agree. That's why I think we should NOT have packagroups inside the BSP metalayer, but in a different layer instead. In a different layer we can have as much as possible/whishable, with as much as possible purposes, colors, sizes. Well, at least for graphics. I'm still trying to convince myself for the other possible BSP packagegroups, but It's very hard to get an argument for it. Daiane > > Ann > > > On 7/11/2015 9:24 AM, Daiane Angolini wrote: > > On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton <Ann.Thornton@freescale.com> > wrote: > > For packagegroup divisions, how about > graphics > multimedia > networking > tools > (probably others I haven't thought of) > > When we think about a set of packagegroups intended to give users a > set of useful packages or an example on how to group applications more > is more. As much as possible is good enough. (meta-fsl-demos) > > However, when you think about a BSP packagegroup, less is more. As > less as possible, as much closer to only critical packages, the > minimal set, is the optimal packagegroup. (meta-fsl-arm) > > Do we need BSP packagegroups? > > In case we do, I cannot see the need of a BSP packagegroup for graphic > (GPU) or tools. > > I would accept "tools" to be split into other sets like "audio", but > definitively not "tools". > > In fact, I can only see the need of a VPU and a CAN package groups. > Maybe audio. But I'm trying to stress the BSP packagegroup idea here, > something I'm not completely convinced of. > > > Daiane > > Each of those groups might be further divided into minimal, core, demos, > extended as needed. > > Each packagegroup could check DISTRO-FEATURES, etc so that they would be as > generic as possible. > > Then recipes could include the level of detail desired and they would work > across product lines. > > Ann Thornton > > > On 7/9/2015 9:56 AM, Daiane Angolini wrote: > > For me, packagegroup is only a set of packages wrapped together to > make my life easier. > > Should BSP provide packagegroups to ease the addition (and removal) of > set o BSP packages, or their “functional” dependency. For example an > application such as aplay is needed to stress the audio functionality, > even though there is no dependency from alsa driver from kernel with > alsa-utils. Should BSP provide packagegroups? > > I think offering packagegroup options to enable BSP pieces may really > ease the BSP usage, however I main point here is how far should BSP > go. What is the limit between a BSP packagegroup and a "demo" > packagegroup (as we does in meta-fsl-demos)? > > Thinking about a package group to provide BSP packages related with > VPU, in my opinion it should have: > > * VPU firmware > * VPU lib > > In case I’m using gstreamer, I would like a packagegroup like: > > * VPU firmware > * VPU lib > * gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin) > > In case I’m using gstreamer with kernel mainline: > > * VPU firmware > * gstreamer > > > Should mp3 encoder (such as lame) be part of a BSP packagegroup? And > in GPU case? Would DEPENDS and PROVIDES be enough to include needed > packages? > > Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP > packagegroup even though there is no special hardware acceleration > provided by meta-fsl-arm for bluetooth? > > > Daiane > > > > -- > Ann Thornton > > Microcontrollers Software and Applications > Freescale Semiconductors > email: Ann.Thornton@freescale.com > > -- > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale > > > > -- > Ann Thornton > > Microcontrollers Software and Applications > Freescale Semiconductors > email: Ann.Thornton@freescale.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BSP Packagegroup 2015-07-15 16:29 ` Daiane Angolini @ 2015-07-15 16:49 ` Otavio Salvador 0 siblings, 0 replies; 6+ messages in thread From: Otavio Salvador @ 2015-07-15 16:49 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale@yoctoproject.org, Ann Thornton On Wed, Jul 15, 2015 at 1:29 PM, Daiane Angolini <daiane.list@gmail.com> wrote: > On Wed, Jul 15, 2015 at 1:21 PM, Ann Thornton > <Ann.Thornton@freescale.com> wrote: >> >> I am thinking of packagegroups as a way to make life easier. Graphics in >> particular is complicated, with some things working in one place and not >> another. Graphics packagegroups can handle a lot of that so a common image >> recipe can easily work in multiple environments and new recipes can be >> created more easily without having to know every detail. Having different >> levels allows an easy way to choose how much to include in a particular >> image. Packagegroups are not specific to BSP or SDK or whatever. They can >> be used wherever desired. > > I agree. > > That's why I think we should NOT have packagroups inside the BSP > metalayer, but in a different layer instead. > > In a different layer we can have as much as possible/whishable, with > as much as possible purposes, colors, sizes. > > Well, at least for graphics. I'm still trying to convince myself for > the other possible BSP packagegroups, but It's very hard to get an > argument for it. If a graphic element is not working we have a dependency problem; packagegroup would be a band-aid, not a solution. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-15 16:49 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-07-09 14:56 BSP Packagegroup Daiane Angolini 2015-07-09 16:29 ` Ann Thornton 2015-07-11 14:24 ` Daiane Angolini 2015-07-15 16:21 ` Ann Thornton 2015-07-15 16:29 ` Daiane Angolini 2015-07-15 16:49 ` Otavio Salvador
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.