Bug 1688

The feature for Hob was in the latest master.

What does this mean?

[P3][D10] Won't be supported in Hob

Shane, does this mean that this won't be there for 1.2 but will be fixed after 1.2?

Song

If it will be done post 1.2, we should keep this bug open and mark its target milestone as 1.3. Thanks!

The new Hob supports multilib functionality, however it requires users to manually add the following lines into local.conf (Sadly this cannot be configured via Hob now, so I think this is why Shane marks it as post 1.3 feature):

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

This can be addressed in 1.3.

Belen,

Please help on the design work for this.

Paul has been helping to determine what the requirements are to enable multilib via the Hob interface. This is what came up in our conversation:

1. enabling multilib involves selecting one or more variants. There are 3 of them listed in /poky/meta/conf/multilib.conf (lib32, lib64 and libx32), but these are only for Intel architecture. Do we know how many variants are there overall?

2. enabling multilib also involves specifying a DEFAULTTUNE for the selected variant. The idea would be not to expose this through Hob though (i.e. selecting a variant in Hob also specifies the required DEFAULTTUNE). This means we need to somehow map each multilib variant to its DEFAULTTUNE.

3. enabling a single multilib variant (e.g. lib32) brings in 18 additional base images. As part of this bug, we might need to tackle 2345 then, because multilib really strains our current interface to select base images.

4. according to Paul, the main multilib use case is building the multilib version of specific recipes / packages (you wouldn't build a whole base image with multilib support). This means that the ability to select the multilib variant for specific recipes / packages is important and needs to be well supported. The problem is that multilib variants are named with a prefix ("lib32-"+<recipe name>), which means that the alphabetical sorting by recipe or package name does not list together a recipe / package and their multilib variants, making selection hard  (if I want to build multilib for acl, I need to go hunting for lib32-acl far down the recipes table). We need to come up with a way of sorting that will put lib32-acl right below acl in the recipes table.

Is there anything else we might be forgetting?

(In reply to comment #8)
> Paul has been helping to determine what the requirements are to enable
> multilib via the Hob interface. This is what came up in our conversation:
> 
> 1. enabling multilib involves selecting one or more variants. There are 3 of
> them listed in /poky/meta/conf/multilib.conf (lib32, lib64 and libx32), but
> these are only for Intel architecture. Do we know how many variants are
> there overall?

Can can determine these from the environment and you can't assume they are static. They can be named anything. In fact I prefer using the what they refer to instead of the canonical names. (eg. ppce500mc -> lib, ppc64e5500 -> lib64)

> 2. enabling multilib also involves specifying a DEFAULTTUNE for the selected
> variant. The idea would be not to expose this through Hob though (i.e.
> selecting a variant in Hob also specifies the required DEFAULTTUNE). This
> means we need to somehow map each multilib variant to its DEFAULTTUNE.

Also, you need to come up with a list of compatible TUNEs. E.g. x86_64 is not compatible with ppce500mc.
 
> 3. enabling a single multilib variant (e.g. lib32) brings in 18 additional
> base images. As part of this bug, we might need to tackle 2345 then, because
> multilib really strains our current interface to select base images.
> 
> 4. according to Paul, the main multilib use case is building the multilib
> version of specific recipes / packages (you wouldn't build a whole base
> image with multilib support). This means that the ability to select the
> multilib variant for specific recipes / packages is important and needs to
> be well supported. The problem is that multilib variants are named with a
> prefix ("lib32-"+<recipe name>), which means that the alphabetical sorting
> by recipe or package name does not list together a recipe / package and
> their multilib variants, making selection hard  (if I want to build multilib
> for acl, I need to go hunting for lib32-acl far down the recipes table). We
> need to come up with a way of sorting that will put lib32-acl right below
> acl in the recipes table.

Maybe you just start with static lists for these in the first pass? x86 and x86_64, ppc and ppc64?

-M

Thanks for the feedback, Matthew.

From what I understand, I guess there are 2 main approaches here:

1. Free text
We provide 2 text fields in Hob where you can enter any values for the variant and the default tune. Advantage of this approach: it's easy to implement.

Problems with this approach:

- People might not know what values they are supposed to enter 
- They might enter an incompatible variant / tune combination

This approach defers responsibility for entering valid input to users, with the software providing little help. 

2. Static list
We provide a list of valid variants, from which users can select one or more. We map those variants to compatible tunes, from which people can select one. 

Advantages: 

- we support users with little knowledge
- we enforce valid input

Disadvantages: we need to specify the variants and their valid tunes somehow. Paul mentioned they could be added to the distro configuration. As Matthew suggests, we could start with a few of them, and add over time. 

Nothing stops us from combine the 2 options above.

Jessica, Cristian, Cristiana: do you have any thoughts on this?

Thanks!

Belen



(In reply to comment #9)
> (In reply to comment #8)
> > Paul has been helping to determine what the requirements are to enable
> > multilib via the Hob interface. This is what came up in our conversation:
> > 
> > 1. enabling multilib involves selecting one or more variants. There are 3 of
> > them listed in /poky/meta/conf/multilib.conf (lib32, lib64 and libx32), but
> > these are only for Intel architecture. Do we know how many variants are
> > there overall?
> 
> Can can determine these from the environment and you can't assume they are
> static. They can be named anything. In fact I prefer using the what they
> refer to instead of the canonical names. (eg. ppce500mc -> lib, ppc64e5500
> -> lib64)
> 
> > 2. enabling multilib also involves specifying a DEFAULTTUNE for the selected
> > variant. The idea would be not to expose this through Hob though (i.e.
> > selecting a variant in Hob also specifies the required DEFAULTTUNE). This
> > means we need to somehow map each multilib variant to its DEFAULTTUNE.
> 
> Also, you need to come up with a list of compatible TUNEs. E.g. x86_64 is
> not compatible with ppce500mc.
>  
> > 3. enabling a single multilib variant (e.g. lib32) brings in 18 additional
> > base images. As part of this bug, we might need to tackle 2345 then, because
> > multilib really strains our current interface to select base images.
> > 
> > 4. according to Paul, the main multilib use case is building the multilib
> > version of specific recipes / packages (you wouldn't build a whole base
> > image with multilib support). This means that the ability to select the
> > multilib variant for specific recipes / packages is important and needs to
> > be well supported. The problem is that multilib variants are named with a
> > prefix ("lib32-"+<recipe name>), which means that the alphabetical sorting
> > by recipe or package name does not list together a recipe / package and
> > their multilib variants, making selection hard  (if I want to build multilib
> > for acl, I need to go hunting for lib32-acl far down the recipes table). We
> > need to come up with a way of sorting that will put lib32-acl right below
> > acl in the recipes table.
> 
> Maybe you just start with static lists for these in the first pass? x86 and
> x86_64, ppc and ppc64?
> 
> -M

At this point, work will take place on toaster, not hob, so marking as won't fix.