RFC: User configurable recipe features
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.
For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the SRC_URI machine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.
For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES = "MDEV"
I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the SRC_URI (or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the SRC_URI to avoid a bug/oversight in the busybox init routine.
I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 7 lines · Darren Hart
I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.
Just chiming in on this point - I think busybox will need something very similar to config fragments. It has a lot of functionality that should be configurable.
-M
Quoted 5 lines · On 10/11/2011 08:53 AM, McClintock Matthew-B29882 wrote:
Quoted 4 lines · Darren Hart
I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).
Quoted 7 lines
Quoted 3 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.Just chiming in on this point - I think busybox will need something very similar to config fragments. It has a lot of functionality that should be configurable.
Agreed, and it can probably use a very similar mechanism to what I've been working to get into the upstream Linux kernel.
I've been looking at the uclibc recipe configuration functions. It looks like it tries to solve a similar problem using feature lists and programatically modifying the .config. More research needed there...
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 30 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like
POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the
SRC_URImachine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES= "MDEV"I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).
Quoted 8 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
We have a few mechanisms around for this but its a difficult problem to do totally generically since everyone has their own ideas about what should/shouldn't happen.
One tricky aspect is that some people care about package feeds and the output into those needs to be deterministic. This is why DISTRO_FEATURES exist which state things like "does x11 make sense"? This means dbus may or may not be compiled with X but given a set of policy decisions by the distro, the output is determined.
Recently we've taken the idea of PACKAGECONFIG on board. This is recipe level policy which can enable/disable features in a given recipe (e.g. does gsteamer depend on and build flac or not?). Whilst we have a high level setup for this for autotools recipes, this is probably something we need to do a more custom implementation of for busybox and the features you mention above would map well to this. It would be good to have a standardised way of representing this (and we may also want to look at moving the kernel feature control towards this variable name too).
What we need to be really really careful about is getting the namespacing right and your CORE_IMAGE_TINY_FEATURES = "VT INET MDEV" example above scares me as it mixes up several different things. My worry is for example trying to build two different versions of busybox in the same tmpdir depending on what image you build, for example what does "bitbake core-image-tiny core-image-sato" do?
Contrast this to some settings:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "mdev"
which then mean you have one set of configuration for these recipes and its clear what the bitbake command above would result in.
One of the bigger problems we're going to have with tiny is its effectively a different set of distro settings to our normal builds. The side effect of that is that you couldn't share a tmpdir with a "big" build but I'm not sure that is an issue in practise, we just need to do it in a way which doesn't give us the nasty configuration corner cases.
So I guess what I'm saying is the end result of your work is likely a "poky-tiny" distro setting which would take the "poky" distro but tweak some pieces for really small images. It would need a separate tmpdir and we should look in the PACKAGECONFIG variable direction for handling recipe specific customisations...
Cheers,
Richard
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment
=============================
Quoted 81 lines · Richard Purdie
Quoted 30 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like
POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the
SRC_URImachine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES= "MDEV"I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).Quoted 8 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
We have a few mechanisms around for this but its a difficult problem to do totally generically since everyone has their own ideas about what should/shouldn't happen.
One tricky aspect is that some people care about package feeds and the output into those needs to be deterministic. This is why
DISTRO_FEATURESexist which state things like "does x11 make sense"? This means dbus may or may not be compiled with X but given a set of policy decisions by the distro, the output is determined.Recently we've taken the idea of PACKAGECONFIG on board. This is recipe level policy which can enable/disable features in a given recipe (e.g. does gsteamer depend on and build flac or not?). Whilst we have a high level setup for this for autotools recipes, this is probably something we need to do a more custom implementation of for busybox and the features you mention above would map well to this. It would be good to have a standardised way of representing this (and we may also want to look at moving the kernel feature control towards this variable name too).
What we need to be really really careful about is getting the namespacing right and your
CORE_IMAGE_TINY_FEATURES= "VT INET MDEV" example above scares me as it mixes up several different things. My worry is for example trying to build two different versions of busybox in the same tmpdir depending on what image you build, for example what does "bitbake core-image-tiny core-image-sato" do?Contrast this to some settings:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "mdev"which then mean you have one set of configuration for these recipes and its clear what the bitbake command above would result in.
One of the bigger problems we're going to have with tiny is its effectively a different set of distro settings to our normal builds. The side effect of that is that you couldn't share a tmpdir with a "big" build but I'm not sure that is an issue in practise, we just need to do it in a way which doesn't give us the nasty configuration corner cases.
Quoted 6 lines
So I guess what I'm saying is the end result of your work is likely a "poky-tiny" distro setting which would take the "poky" distro but tweak some pieces for really small images. It would need a separate tmpdir and we should look in the PACKAGECONFIG variable direction for handling recipe specific customisations...
FWIW I agree it seems like a new distro to me. I think if we add more to mix it just will complicate the customizations and may even make it difficult to share
things.
Quoted 12 lines
Cheers,
Richard
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 90 lines · Khem Raj
Quoted 81 lines · Richard Purdie
Quoted 30 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like
POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the
SRC_URImachine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES= "MDEV"I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).Quoted 8 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
We have a few mechanisms around for this but its a difficult problem to do totally generically since everyone has their own ideas about what should/shouldn't happen.
One tricky aspect is that some people care about package feeds and the output into those needs to be deterministic. This is why
DISTRO_FEATURESexist which state things like "does x11 make sense"? This means dbus may or may not be compiled with X but given a set of policy decisions by the distro, the output is determined.Recently we've taken the idea of PACKAGECONFIG on board. This is recipe level policy which can enable/disable features in a given recipe (e.g. does gsteamer depend on and build flac or not?). Whilst we have a high level setup for this for autotools recipes, this is probably something we need to do a more custom implementation of for busybox and the features you mention above would map well to this. It would be good to have a standardised way of representing this (and we may also want to look at moving the kernel feature control towards this variable name too).
What we need to be really really careful about is getting the namespacing right and your
CORE_IMAGE_TINY_FEATURES= "VT INET MDEV" example above scares me as it mixes up several different things. My worry is for example trying to build two different versions of busybox in the same tmpdir depending on what image you build, for example what does "bitbake core-image-tiny core-image-sato" do?Contrast this to some settings:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "mdev"which then mean you have one set of configuration for these recipes and its clear what the bitbake command above would result in.
One of the bigger problems we're going to have with tiny is its effectively a different set of distro settings to our normal builds. The side effect of that is that you couldn't share a tmpdir with a "big" build but I'm not sure that is an issue in practise, we just need to do it in a way which doesn't give us the nasty configuration corner cases.
Quoted 6 lines
So I guess what I'm saying is the end result of your work is likely a "poky-tiny" distro setting which would take the "poky" distro but tweak some pieces for really small images. It would need a separate tmpdir and we should look in the PACKAGECONFIG variable direction for handling recipe specific customisations...
Quoted 4 lines
FWIW I agree it seems like a new distro to me. I think if we add more to mix it just will complicate the customizations and may even make it difficult to share
things.
Along the same line of thought, does this overlap with the micro distro?
Philip
Quoted 31 lines · Richard Purdie
Quoted 30 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like
POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the
SRC_URImachine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES= "MDEV"I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).
Quoted 9 lines
Quoted 8 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
Hi RP,
Thanks for the thoughts, gives me some places to look for examples and flesh this idea out more.
Quoted 20 lines
We have a few mechanisms around for this but its a difficult problem to do totally generically since everyone has their own ideas about what should/shouldn't happen.
One tricky aspect is that some people care about package feeds and the output into those needs to be deterministic. This is why
DISTRO_FEATURESexist which state things like "does x11 make sense"? This means dbus may or may not be compiled with X but given a set of policy decisions by the distro, the output is determined.Recently we've taken the idea of PACKAGECONFIG on board. This is recipe level policy which can enable/disable features in a given recipe (e.g. does gsteamer depend on and build flac or not?). Whilst we have a high level setup for this for autotools recipes, this is probably something we need to do a more custom implementation of for busybox and the features you mention above would map well to this. It would be good to have a standardised way of representing this (and we may also want to look at moving the kernel feature control towards this variable name too).
Quoted 3 lines
What we need to be really really careful about is getting the namespacing right and your
CORE_IMAGE_TINY_FEATURES= "VT INET MDEV" example above scares me as it mixes up several different things. My
Sure, I'm not attached to it, it was just for illustration.
Quoted 3 lines
worry is for example trying to build two different versions of busybox in the same tmpdir depending on what image you build, for example what does "bitbake core-image-tiny core-image-sato" do?
Yes, I see the problem. I notice that uclibc uses a different tmp space that the eglibc build.
Quoted 5 lines
Contrast this to some settings:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "mdev"
OK, but it would need to be:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "vt inet mdev"
Since busybox needs to disable various vt support configs if the kernel doesn't support vt. If don't support networking in the kernel, we might as well disable it in busybox (and eglibc or uclibc for that matter). The idea behind the single features variable was to avoid having to keep them all in sync. Perhaps the busybox one could also read PACKAGECONFIG_pn-virtual/kernel, but if they have explicitly different settings - because someone wants a generic busybox recipe for multiple kernels for example - I'm not sure how we would reconcile that.
Quoted 9 lines
which then mean you have one set of configuration for these recipes and its clear what the bitbake command above would result in.
One of the bigger problems we're going to have with tiny is its effectively a different set of distro settings to our normal builds. The side effect of that is that you couldn't share a tmpdir with a "big" build but I'm not sure that is an issue in practise, we just need to do it in a way which doesn't give us the nasty configuration corner cases.
For now it has been working alright. I wrote a task-core-tiny task and a core-image-tiny image recipe which just install less stuff, so those work out fine, and get us all the way down to a 3.2M rootfs (down from 11M with minimal) without rewriting recipes or reconfiguring them. So we can do a lot in the existing tmp space.
Obviously with reconfigured recipes or altered sources, we'd either need a new tmp space, or perhaps renamed recipes. I already use linux-yocto-tiny, perhaps busybox-tiny would make sense (although it sounds a tad redundant ;). I don't much like the -tiny recipes as they duplicate code - and the PACKAGECONFIG should do all we need.
Quoted 6 lines
So I guess what I'm saying is the end result of your work is likely a "poky-tiny" distro setting which would take the "poky" distro but tweak some pieces for really small images. It would need a separate tmpdir and we should look in the PACKAGECONFIG variable direction for handling recipe specific customisations...
Thanks RP,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 91 lines · Philip Balister
Quoted 90 lines · Khem Raj
Quoted 87 lines · Richard Purdie
Quoted 30 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like
POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the
SRC_URImachine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES= "MDEV"I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).Quoted 8 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
We have a few mechanisms around for this but its a difficult problem to do totally generically since everyone has their own ideas about what should/shouldn't happen.
One tricky aspect is that some people care about package feeds and the output into those needs to be deterministic. This is why
DISTRO_FEATURESexist which state things like "does x11 make sense"? This means dbus may or may not be compiled with X but given a set of policy decisions by the distro, the output is determined.Recently we've taken the idea of PACKAGECONFIG on board. This is recipe level policy which can enable/disable features in a given recipe (e.g. does gsteamer depend on and build flac or not?). Whilst we have a high level setup for this for autotools recipes, this is probably something we need to do a more custom implementation of for busybox and the features you mention above would map well to this. It would be good to have a standardised way of representing this (and we may also want to look at moving the kernel feature control towards this variable name too).
What we need to be really really careful about is getting the namespacing right and your
CORE_IMAGE_TINY_FEATURES= "VT INET MDEV" example above scares me as it mixes up several different things. My worry is for example trying to build two different versions of busybox in the same tmpdir depending on what image you build, for example what does "bitbake core-image-tiny core-image-sato" do?Contrast this to some settings:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "mdev"which then mean you have one set of configuration for these recipes and its clear what the bitbake command above would result in.
One of the bigger problems we're going to have with tiny is its effectively a different set of distro settings to our normal builds. The side effect of that is that you couldn't share a tmpdir with a "big" build but I'm not sure that is an issue in practise, we just need to do it in a way which doesn't give us the nasty configuration corner cases.
So I guess what I'm saying is the end result of your work is likely a "poky-tiny" distro setting which would take the "poky" distro but tweak some pieces for really small images. It would need a separate tmpdir and we should look in the PACKAGECONFIG variable direction for handling recipe specific customisations...
Quoted 7 lines
Quoted 4 lines
FWIW I agree it seems like a new distro to me. I think if we add more to mix it just will complicate the customizations and may even make it difficult to share
things.Along the same line of thought, does this overlap with the micro distro?
Hrm... the micro distro? What's this?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Op 12 okt. 2011, om 17:41 heeft Darren Hart het volgende geschreven:
Quoted 99 lines · Philip Balister
Quoted 96 lines · Khem Raj
Quoted 94 lines
Quoted 81 lines · Richard Purdie
Quoted 30 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
It is currently possible to affect which packages are installed in an image with variables like
POKY_EXTRA_INSTALL. What I'm not finding a way to do is specify some set of features that will impact how a recipe is built.For example, a user may or may not want networking support or virtual terminal support in their image. This impacts both the kernel and busybox (at least). The linux-yocto infrastructure provides us with config fragment functionality, something similar will need to be added to busybox. Access to that is still bound to the machine config by means of the
SRC_URImachine override mechanism, but it would be useful to be able to influence it from the image config or the user's local config.For example, when building a tiny image I may decide I do not want VT nor INET support. I might wish to specify this like this (by removing them from the default features):
local.conf:
#CORE_IMAGE_TINY_FEATURES = "VT INET MDEV"CORE_IMAGE_TINY_FEATURES= "MDEV"I would want this to affect linux-yocto-tiny by dropping the vt.cfg and inet.cfg fragments from the
SRC_URI(or from the .scc descriptor files assembled by the linux-yocto meta indrastructure).Quoted 8 lines
Busybox would need a similar configuration mechanism, and would also need to add a "no-vt-support.patch" patch to the
SRC_URIto avoid a bug/oversight in the busybox init routine.I'd appreciate some help determining the proper bitbake way of doing this. I want to avoid having to create a new machine.conf and/or recipes for every possible combination of features that a user may want to turn on or off.
We have a few mechanisms around for this but its a difficult problem to do totally generically since everyone has their own ideas about what should/shouldn't happen.
One tricky aspect is that some people care about package feeds and the output into those needs to be deterministic. This is why
DISTRO_FEATURESexist which state things like "does x11 make sense"? This means dbus may or may not be compiled with X but given a set of policy decisions by the distro, the output is determined.Recently we've taken the idea of PACKAGECONFIG on board. This is recipe level policy which can enable/disable features in a given recipe (e.g. does gsteamer depend on and build flac or not?). Whilst we have a high level setup for this for autotools recipes, this is probably something we need to do a more custom implementation of for busybox and the features you mention above would map well to this. It would be good to have a standardised way of representing this (and we may also want to look at moving the kernel feature control towards this variable name too).
What we need to be really really careful about is getting the namespacing right and your
CORE_IMAGE_TINY_FEATURES= "VT INET MDEV" example above scares me as it mixes up several different things. My worry is for example trying to build two different versions of busybox in the same tmpdir depending on what image you build, for example what does "bitbake core-image-tiny core-image-sato" do?Contrast this to some settings:
PACKAGECONFIG_pn-linux-yocto = "vt inet"
PACKAGECONFIG_pn-busybox = "mdev"which then mean you have one set of configuration for these recipes and its clear what the bitbake command above would result in.
One of the bigger problems we're going to have with tiny is its effectively a different set of distro settings to our normal builds. The side effect of that is that you couldn't share a tmpdir with a "big" build but I'm not sure that is an issue in practise, we just need to do it in a way which doesn't give us the nasty configuration corner cases.
Quoted 6 lines
So I guess what I'm saying is the end result of your work is likely a "poky-tiny" distro setting which would take the "poky" distro but tweak some pieces for really small images. It would need a separate tmpdir and we should look in the PACKAGECONFIG variable direction for handling recipe specific customisations...
FWIW I agree it seems like a new distro to me. I think if we add more to mix it just will complicate the customizations and may even make it difficult to share
things.
Quoted 4 lines
Quoted 2 lines
Along the same line of thought, does this overlap with the micro distro?
Hrm... the micro distro? What's this?
Quoted 1 line · On Wednesday 12 October 2011 16:41:56 Darren Hart wrote:
Hrm... the micro distro? What's this?
http://cgit.openembedded.org/meta-micro/
It's maintained by Phil Blundell. I believe he's been pretty successful in reducing size of the resulting image whilst keeping the system fairly functional. He is using uclibc however.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Hi Tim,
Quoted 9 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
Tim,
I'll be presenting things in more detail at ELCE, Friday @ 3:45 PM in the Kepler room. The summary is that I have received a lot of questions along the lines of "How small of an image can I build with Yocto?". core-image-minimal does a decent job at a small general purpose image, but it still has a lot of baggage that a truly size conscious developer doesn't need for a custom BSP.
meta-tiny is my experimental layer where I'm looking at what we can build with our existing sources and infrastructure. I've found that we can cut the image size to about 10% of core-image-minimal without changes to source code, but dropping a lot of functionality. We can get to something like 20% while still maintaining ipv4 networking.
This "recipe features" thread stems from this work. Before I can integrate something like this into Yocto, it needs a more suitable user exposed configuration mechanism.
I'm working from a public git repository, but it isn't in sync with my local development branch as things are changing by the minute still. I will be pushing this to a Yocto hosted git repository in time for ELCE, but it will still be development/experimental. If you are interested in seeing what is there now, you can have a look to get an idea of what I'm doing. Please note this tree WILL rebase, it WILL fail to build, it WILL destroy your tmp dir, your sstate, and waste your time as you try and pick through the various options to get something that builds and boots ;-) Also, this repo will disappear in the next few days, but if you just want to see it, it's here:
http://git.infradead.org/users/dvhart/meta-tiny.git
Quoted 3 lines
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
I'd like to have a look - is there anything out there I can read through?
Post ELCE, I'd like to look at more source level changes we can make. In particular I'd like to see the >200k bzImage increase for ipv4 come down. In addition to that, I'm hoping to take a closer look at dynamic memory usage in the Linux kernel for small systems.
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 8 lines · Paul Eggleton
Quoted 1 line · On Wednesday 12 October 2011 16:41:56 Darren Hart wrote:
Hrm... the micro distro? What's this?
http://cgit.openembedded.org/meta-micro/
It's maintained by Phil Blundell. I believe he's been pretty successful in reducing size of the resulting image whilst keeping the system fairly functional. He is using uclibc however.
I wish I had run across this a few months ago. meta-micro in fact has both an eglibc and a uclibc distro definition. I haven't tried a build, but it does seem to be attempting the same basic thing as meta-tiny - only in a more generally usable way.
This is fine as the end result of meta-tiny is likely to be some improved configuration mechanisms for things like busybox, libc, and the kernel, which should prove useful to meta-micro as well.
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 6 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Quoted 7 lines
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Perhaps while I have the attention of a few interested parties, it would be a good time for a poll. I'm interested in your motivation for smaller images.
Are you building SoC's with memory on die and needing to keep the memory footprint down to save precious die real-estate?
Are you looking at creating mass-market products and saving a few pennies on the flash storage translates to real money, so you want to minimize the physical size?
Are you concerned with boot time, and have connected larger image sizes with longer boot times?
Is there another motivating factor for your interest in small images?
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 15 lines · Darren Hart
Quoted 6 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Quoted 7 lines
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Quoted 6 lines
Perhaps while I have the attention of a few interested parties, it would be a good time for a poll. I'm interested in your motivation for smaller images.
Are you building SoC's with memory on die and needing to keep the memory footprint down to save precious die real-estate?
No.
Quoted 3 lines
Are you looking at creating mass-market products and saving a few pennies on the flash storage translates to real money, so you want to minimize the physical size?
Yes. - this is the primary one for me/Sony. We have dual-core/dual-OS cameras where the ram budget for the Linux side of the device is only 10 meg. We are working on medical products with flash budgets of 8 meg and ram budgets of 4 meg.
We are currently doing a fair amount with execute in place, to conserve RAM versus flash.
Quoted 2 lines
Are you concerned with boot time, and have connected larger image sizes with longer boot times?
Yes.
Quoted 1 line
Is there another motivating factor for your interest in small images?
Smaller images should theoretically run faster, due to less pressure on CPU caches. I don't know of any meaningful measurements of this, but it's an interesting possibility.
Also, it's nice to minimize the memory footprint to reduce power consumption.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment
=============================
Quoted 14 lines · Darren Hart
Hi Tim,
Quoted 9 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
Quoted 5 lines
Tim,
I'll be presenting things in more detail at ELCE, Friday @ 3:45 PM in the Kepler room. The summary is that I have received a lot of questions along the lines of "How small of an image can I build with Yocto?".
I guess yocto needs to define another profile(distro) to really demonstrate how small it can get. There are other distros based on oe-core e.g. micro and even slugos where the image sizes are really small slugos/uclibc image is around 2.7M eglibc based image is 3.5M
Quoted 10 lines
core-image-minimal does a decent job at a small general purpose image, but it still has a lot of baggage that a truly size conscious developer doesn't need for a custom BSP.
meta-tiny is my experimental layer where I'm looking at what we can build with our existing sources and infrastructure. I've found that we can cut the image size to about 10% of core-image-minimal without changes to source code, but dropping a lot of functionality. We can get to something like 20% while still maintaining ipv4 networking.
Quoted 3 lines
This "recipe features" thread stems from this work. Before I can integrate something like this into Yocto, it needs a more suitable user exposed configuration mechanism.
this has a downside. I still favour that distro/machine should be one to dictate the features which should control recipe feature enable/disable behavior.
Quoted 27 lines
I'm working from a public git repository, but it isn't in sync with my local development branch as things are changing by the minute still. I will be pushing this to a Yocto hosted git repository in time for ELCE, but it will still be development/experimental. If you are interested in seeing what is there now, you can have a look to get an idea of what I'm doing. Please note this tree WILL rebase, it WILL fail to build, it WILL destroy your tmp dir, your sstate, and waste your time as you try and pick through the various options to get something that builds and boots ;-) Also, this repo will disappear in the next few days, but if you just want to see it, it's here:
http://git.infradead.org/users/dvhart/meta-tiny.git
Quoted 3 lines
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
I'd like to have a look - is there anything out there I can read through?
Post ELCE, I'd like to look at more source level changes we can make. In particular I'd like to see the>200k bzImage increase for ipv4 come down. In addition to that, I'm hoping to take a closer look at dynamic memory usage in the Linux kernel for small systems.
Thanks,
Quoted 5 lines · Darren Hart
meta-tiny is my experimental layer where I'm looking at what we can build with our existing sources and infrastructure. I've found that we can cut the image size to about 10% of core-image-minimal without changes to source code, but dropping a lot of functionality. We can get to something like 20% while still maintaining ipv4 networking.
This sounds cool.
Quoted 15 lines
This "recipe features" thread stems from this work. Before I can integrate something like this into Yocto, it needs a more suitable user exposed configuration mechanism.
I'm working from a public git repository, but it isn't in sync with my local development branch as things are changing by the minute still. I will be pushing this to a Yocto hosted git repository in time for ELCE, but it will still be development/experimental. If you are interested in seeing what is there now, you can have a look to get an idea of what I'm doing. Please note this tree WILL rebase, it WILL fail to build, it WILL destroy your tmp dir, your sstate, and waste your time as you try and pick through the various options to get something that builds and boots ;-) Also, this repo will disappear in the next few days, but if you just want to see it, it's here:
Quoted 7 lines
http://git.infradead.org/users/dvhart/meta-tiny.git
Quoted 3 lines
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
I'd like to have a look - is there anything out there I can read through?
Not at the moment. I've been meaning to send my patch for 4K stack support for ARM to linux-ARM, but haven't had the time. I'll see if I can push it out this week (but it might collide with the 3.2 merge window, and I wouldn't expect it to go straight in without it dwelling in someone's -next tree for a bit.)
In our cameras, this saves about 300K of kernel memory.
I have no problem sending that to you if you'd like. Just let me know. If mainline doesn't take it straight-away for some reason, I'll probably hand it off to the linux-tiny project, which is back in full swing.
Quoted 4 lines
Post ELCE, I'd like to look at more source level changes we can make. In particular I'd like to see the >200k bzImage increase for ipv4 come down. In addition to that, I'm hoping to take a closer look at dynamic memory usage in the Linux kernel for small systems.
I have some patches for monitoring slab allocations that are helpful for this (also something I should have already mainlined, but didn't get to... ;-(
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment
=============================
Quoted 13 lines · Darren Hart
Quoted 10 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
Quoted 7 lines
Quoted 3 lines
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Perhaps while I have the attention of a few interested parties, it would be a good time for a poll. I'm interested in your motivation for smaller images.
I am not on the front line but here is my take.
Quoted 3 lines
Are you building SoC's with memory on die and needing to keep the memory footprint down to save precious die real-estate?
no.
However we sometimes run the full fileystem from DDR so there is no flash per say. (Full filesystem image gets transfered at boot time). Board with N devices, all with DDR and ethernet and nothing else. Don't use NFS for latency/performance consistency issues.
Quoted 4 lines
Are you looking at creating mass-market products and saving a few pennies on the flash storage translates to real money, so you want to minimize the physical size?
Yes.
We still see flash size == to RAM size or 1/2 RAM. 32 MB RAM, 16 MB Flash
64 MB RAM, 32 MB flash
We had one EVM w/ 8 MB SPI flash and we fit a fairly decent headless system into that. Not sure if that was customer driven or bad EVM definition. Fortunity that EVM also had a MMC/SD card reader for the > 8MB use case.
Of course once you go above a certain size (128/256 MB), people go MMC/SD and then minimums go way up. 1 GB is probably as cheap as 512MB.
We have not seen the situation Tim talked about with RAM < NVMEM (at least not for several years)
If you start getting into the oversize microcontroller area then you start getting very small. However you are also probably only a kernel, uclibc, a very cut down busybox and one or two custom apps.
Quoted 4 lines
Are you concerned with boot time, and have connected larger image sizes with longer boot times?
That is a nice benefit but not the main objective.
Better use case for seep cases is a partitioned NVMEM configuration with small faster flash (32MB-256MB parallel NAND) and slower larger storage (1+ GB SD Card etc).
With this config do you:
* treat the NAND as a dynamic FS cache
* use it to store the "core" os (/ but not /usr or /opt)
* use it to store only readahead like data
Quoted 4 lines
Is there another motivating factor for your interest in small images?
Thanks,
Op 12 okt. 2011, om 20:44 heeft Khem Raj het volgende geschreven:
Quoted 15 lines · Darren Hart
Quoted 14 lines
Hi Tim,
Quoted 9 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
Quoted 7 lines
Quoted 5 lines
Tim,
I'll be presenting things in more detail at ELCE, Friday @ 3:45 PM in the Kepler room. The summary is that I have received a lot of questions along the lines of "How small of an image can I build with Yocto?".
I guess yocto needs to define another profile(distro) to really demonstrate how small it can get. There are other distros based on oe-core e.g. micro and even slugos where the image sizes are really small slugos/uclibc image is around 2.7M eglibc based image is 3.5M
And don't forget angstrom, that scales all the way down to an fbdev gui fit inside 80kiB.
Quoted 20 lines · Koen Kooi
Op 12 okt. 2011, om 20:44 heeft Khem Raj het volgende geschreven:
Quoted 17 lines · Darren Hart
Quoted 16 lines
Hi Tim,
Quoted 9 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
Tim,
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I'll be presenting things in more detail at ELCE, Friday @ 3:45 PM in the Kepler room. The summary is that I have received a lot of questions along the lines of "How small of an image can I build with Yocto?".
I guess yocto needs to define another profile(distro) to really demonstrate how small it can get. There are other distros based on oe-core e.g. micro and even slugos where the image sizes are really small slugos/uclibc image is around 2.7M eglibc based image is 3.5M
And don't forget angstrom, that scales all the way down to an fbdev gui fit inside 80kiB.
indeed.
Quoted 17 lines · Khem Raj
Quoted 16 lines · Darren Hart
Hi Tim,
Quoted 9 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
Tim,
Quoted 8 lines
Quoted 3 lines
I'll be presenting things in more detail at ELCE, Friday @ 3:45 PM in the Kepler room. The summary is that I have received a lot of questions along the lines of "How small of an image can I build with Yocto?".
I guess yocto needs to define another profile(distro) to really demonstrate how small it can get. There are other distros based on oe-core e.g. micro and even slugos where the image sizes are really small slugos/uclibc image is around 2.7M eglibc based image is 3.5M
That's right about what I'm seeing as well, and it's not particularly difficult to get there. It was mostly just time consuming. If we can make it easy to start there and let people build up from there, I think taht would be a win.
Quoted 11 lines
Quoted 11 lines
core-image-minimal does a decent job at a small general purpose image, but it still has a lot of baggage that a truly size conscious developer doesn't need for a custom BSP.
meta-tiny is my experimental layer where I'm looking at what we can build with our existing sources and infrastructure. I've found that we can cut the image size to about 10% of core-image-minimal without changes to source code, but dropping a lot of functionality. We can get to something like 20% while still maintaining ipv4 networking.
Quoted 7 lines
Quoted 3 lines
This "recipe features" thread stems from this work. Before I can integrate something like this into Yocto, it needs a more suitable user exposed configuration mechanism.
this has a downside. I still favour that distro/machine should be one to dictate the features which should control recipe feature enable/disable behavior.
I don't disagree. The configuration mechanism is still needed though. For example, the only way to configure bitbake as things stand is with a new defconfig. By adding config fragment management and some sort of selectable feature set, each distro definition could provide it's own config and build from the same recipe. Much the way uclibc and eglibc can be configured now (and use distro defined variables).
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 14 lines · Darren Hart
Quoted 5 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Quoted 7 lines
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Quoted 6 lines
Perhaps while I have the attention of a few interested parties, it would be a good time for a poll. I'm interested in your motivation for smaller images.
Are you building SoC's with memory on die and needing to keep the memory footprint down to save precious die real-estate?
no
Quoted 4 lines
Are you looking at creating mass-market products and saving a few pennies on the flash storage translates to real money, so you want to minimize the physical size?
no
Quoted 3 lines
Are you concerned with boot time, and have connected larger image sizes with longer boot times?
I am concerned with boot time, but don't believe it is image size that ramps it up.
Quoted 2 lines
Is there another motivating factor for your interest in small images?
Yes, a smaller system which is easier to check, build and maintain. In my office I am the leading driver for using linux in a team of 3 (two software, one fpga developer) so the less time I spend building, rebuilding and checking features I don't need, to ensure they don't comprimise the stability of the system, the more faith they have in the system I'm putting forward.
Quoted 3 lines
Thanks,
Quoted 35 lines · Jack Mitchell
Quoted 14 lines · Darren Hart
Quoted 5 lines · Tim Bird
Quoted 4 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local configuration file that will impact the build of the image and a set of recipes.
Quoted 7 lines
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Quoted 6 lines
Perhaps while I have the attention of a few interested parties, it would be a good time for a poll. I'm interested in your motivation for smaller images.
Are you building SoC's with memory on die and needing to keep the memory footprint down to save precious die real-estate?
no
Quoted 4 lines
Are you looking at creating mass-market products and saving a few pennies on the flash storage translates to real money, so you want to minimize the physical size?
no
Quoted 3 lines
Are you concerned with boot time, and have connected larger image sizes with longer boot times?
Quoted 7 lines
I am concerned with boot time, but don't believe it is image size that ramps it up.
Quoted 2 lines
Is there another motivating factor for your interest in small images?
Yes, a smaller system which is easier to check, build and maintain. In my office I am the leading driver for using linux in a team of 3 (two software, one fpga developer) so the less time I spend building, rebuilding and checking features I don't need, to ensure they don't comprimise the stability of the system, the more faith they have in the system I'm putting forward.
Ahhh, nice one Jack.
I had a similar thought this morning. As the target system gets smaller the tolerance for spending X amount of time building non-target code goes down and the expectation of being able to use a "modest machine" goes up.
What is a modest machine? Yocto quotes build times for a "refernce machine" that is pretty up to date and not on the low end. To me, a modest machine is the laptop Mom & Dad bought "Stacy" when she graduated from High School and went off to College. Stacy is now a junior and is exploring embedded Linux. This might be an i3 2 GB machine. A China based startup may also give its engineers modest machines. I think many TI'ers would claim they have been stuck on modest machines for long periods.
So If a sato image takes 1 hour to build on the reference machine it may take 4 hours to build on a modest machine. Of that time perhaps 1 hr is spent building host side stuff.
If your image is just kernel, busybox, and uclibc you probably only spend 1/2 hour building that on a modest machine. Question is does oe-core/poky still make you build 1 hr worth of host stuff?
I know Richard's answer will be shared state but I want to see how that really works out. This is an area we plan on playing with over the next release cycle.
Quoted 6 lines
Quoted 2 lines
Thanks,
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 71 lines · William Mills
Quoted 44 lines · Jack Mitchell
Quoted 18 lines · Darren Hart
Quoted 9 lines · Tim Bird
Quoted 6 lines · Darren Hart
As part of working on meta-tiny, I've come across a need (want?) to present users with the ability to select some set of features in a local
configuration file that will impact the build of the image and a set of recipes.Quoted 7 lines
Can you tell me more about meta-tiny? this is the first I've heard about this (sorry if discussion went by on the mailing list and I missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including some work to support 4K stacks).
Quoted 6 lines
Perhaps while I have the attention of a few interested parties, it would be a good time for a poll. I'm interested in your motivation for smaller images.
Are you building SoC's with memory on die and needing to keep the memory footprint down to save precious die real-estate?
no
Quoted 4 lines
Are you looking at creating mass-market products and saving a few pennies on the flash storage translates to real money, so you want to minimize the physical size?
no
Quoted 3 lines
Are you concerned with boot time, and have connected larger image sizes with longer boot times?
I am concerned with boot time, but don't believe it is image size that ramps it up.
Quoted 1 line
Quoted 9 lines
Quoted 1 line
Is there another motivating factor for your interest in small images?
Yes, a smaller system which is easier to check, build and maintain. In my office I am the leading driver for using linux in a team of 3 (two software, one fpga developer) so the less time I spend building, rebuilding and checking features I don't need, to ensure they don't comprimise the stability of the system, the more faith they have in the system I'm putting forward.
Ahhh, nice one Jack.
I had a similar thought this morning. As the target system gets smaller the tolerance for spending X amount of time building non-target code goes down and the expectation of being able to use a "modest machine" goes up.
What is a modest machine? Yocto quotes build times for a "refernce machine" that is pretty up to date and not on the low end. To me, a modest machine is the laptop Mom & Dad bought "Stacy" when she graduated from High School and went off to College. Stacy is now a junior and is exploring embedded Linux. This might be an i3 2 GB machine. A China based startup may also give its engineers modest machines. I think many TI'ers would claim they have been stuck on modest machines for long periods.
Quoted 7 lines
So If a sato image takes 1 hour to build on the reference machine it may take 4 hours to build on a modest machine. Of that time perhaps 1 hr is spent building host side stuff.
If your image is just kernel, busybox, and uclibc you probably only spend 1/2 hour building that on a modest machine. Question is does oe-core/poky still make you build 1 hr worth of host stuff?
Usually some of the host distros have sane(for OE sense) versions of host packages. You might experiment usingASSUME_PROVIDED for the build host packages this will then use the packages from your build system
however the results you get might be different than others that's one reason for host packages
A lot of stuff in OE environment is done to ensure predictability of builds on different host distros
which is a good thing IMO.
Quoted 18 lines
I know Richard's answer will be shared state but I want to see how that really works out. This is an area we plan on playing with over the next release cycle.
Quoted 6 lines
Quoted 2 lines
Thanks,
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto