RFC: Image Creator and Config Creator, design thoughts
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Darren Hart
I sat down with Josh earlier this week to discuss how I might use the Image Creator in my development and to address any issues that might pose as blockers to my finding such a tool useful. This led to various feature discussions, scope setting, etc. I wanted to capture that here and also ask for comments from other users and developers.
Quoted 6 lines
Image Recipe Generation
-----------------------
The image creator Josh is working on currently facilitates specifying the policy (bitbake term "distro", such as poky, poky-bleeding, or poky-lsb), image, and any additional packages you may want to include. It then provides a simple wrapper to bitbake and it's output.
Aside, wrapper is not the right term. This is a full fledged BitBake GUI and uses the same libraries as the CLI (knotty) interface. :-)
Quoted 14 lines
This is
useful in and of itself as sorting out which variables to modify (IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc) and which tasks to rebuild (task_base,task_machine_base, poky-image-*, etc.) can be a frustrating exercise (or at least it has been for me).In order for this feature to be the most useful, it needs to be able to save the result of the user's selection. This involves saving off the "distro" selection (typically in local.conf) as well as an image recipe defining which packages to include in the resulting image. This could be done by writing to local.conf and saving a new *image*.bb file in a suitable location.
Quoted 5 lines
Writing Layers
--------------
The suitable location is most likely a layer, which suggests the Image Builder should probably know how to construct a basic layer skeleton and prompt the user to fill in the descriptive bits required for layer.conf.
This sounds like a useful way to handle the customisations.
Quoted 6 lines
I could see this as having been useful for the recent Yocto Project 1.0 launch demo we worked on, which added rygel upnp video renderers to the the 0.9 audio only demo. This implies the Image Builder should also be able to work with an existing layer - perhaps only those that it created
- and save the changes back to that layer.
Layer support is definitely something I'd like to see in the Image Creator. I'm thinking along the lines of a GUI for toggling available layers enabled state.
Further to the suggestion above this GUI would likely also include a "Save my customisations to this layer" entry.
Quoted 27 lines
Configuration Fragments
-----------------------
In order to properly build the demo images (poky-image-rygel specifically) some specific license related variables need to be set, typically in local.conf:
COMMERCIAL_LICENSE= ""COMMERCIAL_AUDIO_PLUGINS?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"COMMERCIAL_VIDEO_PLUGINS?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"Without the above, the upnp demo is mostly non-functional. Having to manually add these sorts of settings significantly reduces the value of the Image Builder in my mind. This led to the discussion of providing a graphical mechanism to set the variables that have some impact on how the generated image recipe is built.
Something like a Linux kernel kconfig mechanism, which only shows the user relevant options (albeit still WAY too many), might be really nice here. Perhaps an interface that parsed the recipes included in the image recipe and determined which variables would be relevant to the user and present those in the UI with help derived from documentation.conf doctags (or perhaps a new mechanism).
Quoted 4 lines
As this would be a considerable effort, and would surely delay the progress of the image builder itself, perhaps a Configuration Editor would be a good companion tool which the Image Builder could launch to do the relevant configurations
I really like the idea of a configuration editor GUI, I'm pretty sure Jeff Polk would like at least some of the infrastructure of this.
I haven't yet gotten around to investigating this but I think between the doctags and the oetypes support Chris Larson implemented (which we still need to pullit into oe-core iirc) we should have a solid foundation on which to build this GUI.
Quoted 12 lines
Conclusions
-----------
The goal of any user interface should be to abstract away to implementation details that are not particularly relevant to task at hand, or to the user's perception of the task at hand. I feel these tools as discussed above would help contain feature creep, while still allowing for a more complete graphical interface to configuring and building images.
Quoted 1 line
Thoughts? Criticisms?
Unsurprisingly, since I was there, I'm in agreement.
Cheers,
Joshua
Signature · 3 lines
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology CenterQuoted 57 lines · Darren Hart
I sat down with Josh earlier this week to discuss how I might use the Image Creator in my development and to address any issues that might pose as blockers to my finding such a tool useful. This led to various feature discussions, scope setting, etc. I wanted to capture that here and also ask for comments from other users and developers.
Image Recipe Generation
-----------------------
The image creator Josh is working on currently facilitates specifying the policy (bitbake term "distro", such as poky, poky-bleeding, or poky-lsb), image, and any additional packages you may want to include. It then provides a simple wrapper to bitbake and it's output. This is useful in and of itself as sorting out which variables to modify (IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc) and which tasks to rebuild (task_base,task_machine_base, poky-image-*, etc.) can be a frustrating exercise (or at least it has been for me).In order for this feature to be the most useful, it needs to be able to save the result of the user's selection. This involves saving off the "distro" selection (typically in local.conf) as well as an image recipe defining which packages to include in the resulting image. This could be done by writing to local.conf and saving a new *image*.bb file in a suitable location.
Writing Layers
--------------
The suitable location is most likely a layer, which suggests the Image Builder should probably know how to construct a basic layer skeleton and prompt the user to fill in the descriptive bits required for layer.conf.I could see this as having been useful for the recent Yocto Project 1.0 launch demo we worked on, which added rygel upnp video renderers to the the 0.9 audio only demo. This implies the Image Builder should also be able to work with an existing layer - perhaps only those that it created
- and save the changes back to that layer.Configuration Fragments
-----------------------
In order to properly build the demo images (poky-image-rygel specifically) some specific license related variables need to be set, typically in local.conf:
COMMERCIAL_LICENSE= ""COMMERCIAL_AUDIO_PLUGINS?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"COMMERCIAL_VIDEO_PLUGINS?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"Without the above, the upnp demo is mostly non-functional. Having to manually add these sorts of settings significantly reduces the value of the Image Builder in my mind. This led to the discussion of providing a graphical mechanism to set the variables that have some impact on how the generated image recipe is built.
Quoted 7 lines
Something like a Linux kernel kconfig mechanism, which only shows the user relevant options (albeit still WAY too many), might be really nice here. Perhaps an interface that parsed the recipes included in the image recipe and determined which variables would be relevant to the user and present those in the UI with help derived from documentation.conf doctags (or perhaps a new mechanism).
Input we got from the ELC talk suggested that people did think it would be intuitive and useful to expand the kernel menuconfig 'UI' down to all the other packages in the image.
I've used UIs designed like that in other build systems and it was very useful, so I'd add my +1 to the ELC requests...
Tom
Quoted 19 lines
As this would be a considerable effort, and would surely delay the progress of the image builder itself, perhaps a Configuration Editor would be a good companion tool which the Image Builder could launch to do the relevant configurations
Conclusions
-----------
The goal of any user interface should be to abstract away to implementation details that are not particularly relevant to task at hand, or to the user's perception of the task at hand. I feel these tools as discussed above would help contain feature creep, while still allowing for a more complete graphical interface to configuring and building images.Thoughts? Criticisms?
Quoted 66 lines · Tom Zanussi
Quoted 57 lines · Darren Hart
I sat down with Josh earlier this week to discuss how I might use the Image Creator in my development and to address any issues that might pose as blockers to my finding such a tool useful. This led to various feature discussions, scope setting, etc. I wanted to capture that here and also ask for comments from other users and developers.
Image Recipe Generation
-----------------------
The image creator Josh is working on currently facilitates specifying the policy (bitbake term "distro", such as poky, poky-bleeding, or poky-lsb), image, and any additional packages you may want to include. It then provides a simple wrapper to bitbake and it's output. This is useful in and of itself as sorting out which variables to modify (IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc) and which tasks to rebuild (task_base,task_machine_base, poky-image-*, etc.) can be a frustrating exercise (or at least it has been for me).In order for this feature to be the most useful, it needs to be able to save the result of the user's selection. This involves saving off the "distro" selection (typically in local.conf) as well as an image recipe defining which packages to include in the resulting image. This could be done by writing to local.conf and saving a new *image*.bb file in a suitable location.
Writing Layers
--------------
The suitable location is most likely a layer, which suggests the Image Builder should probably know how to construct a basic layer skeleton and prompt the user to fill in the descriptive bits required for layer.conf.I could see this as having been useful for the recent Yocto Project 1.0 launch demo we worked on, which added rygel upnp video renderers to the the 0.9 audio only demo. This implies the Image Builder should also be able to work with an existing layer - perhaps only those that it created
- and save the changes back to that layer.Configuration Fragments
-----------------------
In order to properly build the demo images (poky-image-rygel specifically) some specific license related variables need to be set, typically in local.conf:
COMMERCIAL_LICENSE= ""COMMERCIAL_AUDIO_PLUGINS?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"COMMERCIAL_VIDEO_PLUGINS?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"Without the above, the upnp demo is mostly non-functional. Having to manually add these sorts of settings significantly reduces the value of the Image Builder in my mind. This led to the discussion of providing a graphical mechanism to set the variables that have some impact on how the generated image recipe is built.
Quoted 7 lines
Something like a Linux kernel kconfig mechanism, which only shows the user relevant options (albeit still WAY too many), might be really nice here. Perhaps an interface that parsed the recipes included in the image recipe and determined which variables would be relevant to the user and present those in the UI with help derived from documentation.conf doctags (or perhaps a new mechanism).
Quoted 6 lines
Input we got from the ELC talk suggested that people did think it would be intuitive and useful to expand the kernel menuconfig 'UI' down to all the other packages in the image.
I've used UIs designed like that in other build systems and it was very useful, so I'd add my +1 to the ELC requests...
And I'd add another +1 to that.
Bruce
Quoted 28 lines
Tom
Quoted 16 lines
As this would be a considerable effort, and would surely delay the progress of the image builder itself, perhaps a Configuration Editor would be a good companion tool which the Image Builder could launch to do the relevant configurations
Conclusions
-----------
The goal of any user interface should be to abstract away to implementation details that are not particularly relevant to task at hand, or to the user's perception of the task at hand. I feel these tools as discussed above would help contain feature creep, while still allowing for a more complete graphical interface to configuring and building images.Quoted 3 lines
Thoughts? Criticisms?
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 67 lines · Bruce Ashfield
Quoted 66 lines · Tom Zanussi
Quoted 64 lines · Darren Hart
I sat down with Josh earlier this week to discuss how I might use the Image Creator in my development and to address any issues that might pose as blockers to my finding such a tool useful. This led to various feature discussions, scope setting, etc. I wanted to capture that here and also ask for comments from other users and developers.
Image Recipe Generation
-----------------------
The image creator Josh is working on currently facilitates specifying the policy (bitbake term "distro", such as poky, poky-bleeding, or poky-lsb), image, and any additional packages you may want to include. It then provides a simple wrapper to bitbake and it's output. This is useful in and of itself as sorting out which variables to modify (IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc) and which tasks to rebuild (task_base,task_machine_base, poky-image-*, etc.) can be a frustrating exercise (or at least it has been for me).In order for this feature to be the most useful, it needs to be able to save the result of the user's selection. This involves saving off the "distro" selection (typically in local.conf) as well as an image recipe defining which packages to include in the resulting image. This could be done by writing to local.conf and saving a new *image*.bb file in a suitable location.
Writing Layers
--------------
The suitable location is most likely a layer, which suggests the Image Builder should probably know how to construct a basic layer skeleton and prompt the user to fill in the descriptive bits required for layer.conf.I could see this as having been useful for the recent Yocto Project 1.0 launch demo we worked on, which added rygel upnp video renderers to the the 0.9 audio only demo. This implies the Image Builder should also be able to work with an existing layer - perhaps only those that it created
- and save the changes back to that layer.Configuration Fragments
-----------------------
In order to properly build the demo images (poky-image-rygel specifically) some specific license related variables need to be set, typically in local.conf:
COMMERCIAL_LICENSE= ""COMMERCIAL_AUDIO_PLUGINS?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"COMMERCIAL_VIDEO_PLUGINS?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"Without the above, the upnp demo is mostly non-functional. Having to manually add these sorts of settings significantly reduces the value of the Image Builder in my mind. This led to the discussion of providing a graphical mechanism to set the variables that have some impact on how the generated image recipe is built.
Something like a Linux kernel kconfig mechanism, which only shows the user relevant options (albeit still WAY too many), might be really nice here. Perhaps an interface that parsed the recipes included in the image recipe and determined which variables would be relevant to the user and present those in the UI with help derived from documentation.conf doctags (or perhaps a new mechanism).
Quoted 9 lines
Quoted 6 lines
Input we got from the ELC talk suggested that people did think it would be intuitive and useful to expand the kernel menuconfig 'UI' down to all the other packages in the image.
I've used UIs designed like that in other build systems and it was very useful, so I'd add my +1 to the ELC requests...
And I'd add another +1 to that.
So the kernel guys agree that menuconfig should used everywhere. Surprise, Surprise. ;-)
--
Darren
Quoted 32 lines
Bruce
Quoted 28 lines
Tom
Quoted 16 lines
As this would be a considerable effort, and would surely delay the progress of the image builder itself, perhaps a Configuration Editor would be a good companion tool which the Image Builder could launch to do the relevant configurations
Conclusions
-----------
The goal of any user interface should be to abstract away to implementation details that are not particularly relevant to task at hand, or to the user's perception of the task at hand. I feel these tools as discussed above would help contain feature creep, while still allowing for a more complete graphical interface to configuring and building images.Quoted 3 lines
Thoughts? Criticisms?
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel