MIPS vs MIPS32 tunings -- summary and questions

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

Quoted 64 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

Quoted 8 lines

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However, as Phil pointed out, there are many more optimization settings, e.g. -O2 vs. -Os, that aren't encoded into the package arch, so the goal to have distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE, you'd usually compile all your applications for the package arch of your target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 7 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 7 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 5 lines

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 3 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Quoted 118 lines · Andreas Oberritter

Quoted 64 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

Quoted 8 lines

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However, as Phil pointed out, there are many more optimization settings, e.g. -O2 vs. -Os, that aren't encoded into the package arch, so the goal to have distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE, you'd usually compile all your applications for the package arch of your target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 7 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 7 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 5 lines

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 3 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

Quoted 3 lines

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I

expect this to be corrected before the release, or should anybody relying on mipsel package feeds stop using oe-core's meta/conf/machine/include/mips/arch-mips.inc?

Regards,
Andreas

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 114 lines · Andreas Oberritter

Quoted 64 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

Quoted 8 lines

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However, as Phil pointed out, there are many more optimization settings, e.g. -O2 vs. -Os, that aren't encoded into the package arch, so the goal to have distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE, you'd usually compile all your applications for the package arch of your target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 7 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 7 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 5 lines

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 7 lines

Quoted 3 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I expect this to be corrected before the release, or should anybody relying on mipsel package feeds stop using oe-core's meta/conf/machine/include/mips/arch-mips.inc?

Quoted 123 lines · Andreas Oberritter

Quoted 114 lines · Andreas Oberritter

Quoted 64 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

Quoted 8 lines

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However, as Phil pointed out, there are many more optimization settings, e.g. -O2 vs. -Os, that aren't encoded into the package arch, so the goal to have distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE, you'd usually compile all your applications for the package arch of your target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 7 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 7 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 5 lines

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 7 lines

Quoted 3 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Quoted 6 lines

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I expect this to be corrected before the release, or should anybody relying on mipsel package feeds stop using oe-core's meta/conf/machine/include/mips/arch-mips.inc?

Sorry, I got distracted by a ton of other issues. I think the cleanup did make sense and things are more correct now, its just a shame about the package feed naming issue.

There comes a point we need to try and clean up some of these things so my proposal would be that people who don't want to use the new naming set the following in their distro config:

MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"

and then should still be able to use the arch-mips.inc from OE-Core. Does that work for people?

Quoted 129 lines · Andreas Oberritter

Quoted 127 lines · Andreas Oberritter

Quoted 74 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not
the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our
current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips"
to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

Quoted 2 lines

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However, as Phil pointed out, there are many more optimization settings, e.g. -O2 vs. -Os, that aren't encoded into the package arch, so the goal to have distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE, you'd usually compile all your applications for the package arch of your target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 7 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 8 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being
equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 6 lines

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no
compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 3 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Quoted 3 lines

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I

I'm a little confused with this, I've just done a build with MACHINE = "qemumips", both build and runqemu worked well.

Quoted 139 lines · Richard Purdie

Quoted 123 lines · Andreas Oberritter

Quoted 114 lines · Andreas Oberritter

Quoted 64 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in the recent thread "conf/machine/include: Cleanup MIPS tunings to match README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns that the GNU target arch had changed (from mips to mips32), this was not the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be some mips3 or mips4 targets, but we find it highly unlikely based on our current experience. Khem suggested resolving this my simply making the "mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

Quoted 8 lines

2) Keep it as it is currently checked in. Provide the ability to build a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4? mips32r2?) tunes could be used to augment this for specific systems.

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However, as Phil pointed out, there are many more optimization settings, e.g. -O2 vs. -Os, that aren't encoded into the package arch, so the goal to have distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE, you'd usually compile all your applications for the package arch of your target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 7 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 7 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 5 lines

3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 7 lines

Quoted 3 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either way if this is the chosen direction.

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Quoted 6 lines

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I expect this to be corrected before the release, or should anybody relying on mipsel package feeds stop using oe-core's meta/conf/machine/include/mips/arch-mips.inc?

Sorry, I got distracted by a ton of other issues. I think the cleanup did make sense and things are more correct now, its just a shame about the package feed naming issue.

There comes a point we need to try and clean up some of these things so my proposal would be that people who don't want to use the new naming set the following in their distro config:

Quoted 4 lines

MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"

and then should still be able to use the arch-mips.inc from OE-Core. Does that work for people?

I wonder why this point has to be during the stabilisation phase before the release, considering much less intrusive changes are not getting applied.

Setting this variable is a partial workaround. PACKAGE_EXTRA_ARCHS also broke for tune-mips32.inc, so this has to be set, too. The easiest thing for everybody would however be to revert "Cleanup MIPS tunings to match README" and to drop tune-mips, which was unused.

Maybe I would have understood why the patch "Cleanup MIPS tunings to match README" was applied, if the README hadn't been created just the same day. Usually the README should describe how something works and not serve as an artificial reason to break things.

If the overall conclusion is that optimisation settings should be encoded in the package architecture, I still wonder why -Os and -O2 aren't encoded or why tune-mips still creates 'mips' and not 'mips1' packages.

So, inconsistent but deployed code has been replaced by inconsistent but new code. And there's no time left to improve the new inconsistent code so short before the release, I guess.

Sorry for the rant.

Regards,
Andreas

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 5 lines · Andreas Oberritter

Quoted 3 lines · Andreas Oberritter

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Quoted 3 lines

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I

I'm a little confused with this, I've just done a build with MACHINE = "qemumips", both build and runqemu worked well.

Quoted 169 lines · Andreas Oberritter

Quoted 168 lines · Richard Purdie

Quoted 152 lines · Andreas Oberritter

Quoted 142 lines · Andreas Oberritter

Quoted 88 lines · Mark Hatle

We still do not have a clean answer for how to resolve the concerns in
the recent thread "conf/machine/include: Cleanup MIPS tunings to match
README". The following is in response to a request I received to summarize the discussion so far, and include the options to resolve the
issue for the current OE-Core release.

If you are interested in this, please be sure to read until the end before commenting.

Background:

About 2 weeks ago, in response to a number of patches sent for PowerPC
issues, I set to the task of documenting and cleaning up the various tune files. It was discovered that since they were originally implemented, a number of minor conflicts and defects had crept into the
system. The recent patch set added a number of README files and attempted to resolve any duplication, or confusion between items.

During this work it was discovered that there were two tunings that produced the same package architecture:

mips (tune), optimized for mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), optimized for mips32 - o32 ABI, produced packages also with a "mips" arch.

While "mips1" should work on a "mips32" system, the reverse is not true. There was no way to distinguish, in a package feed, the difference between the two sets of binaries.

I updated the MIPS tune files to resolve this issue. The result was:

mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch

mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch

This lead to the thread mentioned above. At first there were concerns
that the GNU target arch had changed (from mips to mips32), this was not
the case. The only change is in the produced package arch names. So the package feeds and image generation are the only components affected
by this change.

After various discussion with folks, such as Khem Raj, it is unlikely that anyone would be using oe-core with a "mips1" target. There may be
some mips3 or mips4 targets, but we find it highly unlikely based on our
current experience. Khem suggested resolving this my simply making the
"mips" include mips32 as the default optimization.

Image generation was verified to produce the same images before and after this change for the qemumips target. I am unable to verify the package feeds, as I do not have a suitable setup for this.

So possible solutions to this particular issue, which we do need on prior to the upcoming release:

1) Revert the behavior and match that last release. We have two tunes
that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to
implement
the defect

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips package arch

2) Keep it as it is currently checked in. Provide the ability to build
a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for
"mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4?
mips32r2?) tunes could be used to augment this for specific systems.

Quoted 2 lines

mips (tune) - mips1 processor, o32 ABI - mips package arch mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch

If the tune should reflect the optimization, then mips should be renamed
to mips1 and specified explicitly using -march=mips1, in order to protect against changing defaults when using a newer compiler. However,
as Phil pointed out, there are many more optimization settings, e.g. -O2
vs. -Os, that aren't encoded into the package arch, so the goal to have
distinct package archs for different binaries won't be reached.

I don't see what a common "mips" package arch would give us. Within OE,
you'd usually compile all your applications for the package arch of your
target system. Adding compatible package archs to the feed just increases the complexity of online updates.

Quoted 8 lines

3) Define only one mips tune, with a target package arch of "mips". Changing the basic mips tune, and corresponding mips package arch to include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and
that
tune will not be compatible with "mips"

Also, mips1 could be added back anytime if anybody starts using it.

Quoted 8 lines

mips (tune) - mips32 processor, o32 ABI - mips package arch

3a) Preserve the mips32 tune entries, but define it as being
equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?

Quoted 7 lines

3b) Remove the mips32 tune entries -- effectively eliminating
mips32
as a tune
* Removes the tune entries (cleans up the tunes), no
compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their machine's DEFAULTTUNE.

Actually I have (had) machines specifying mips32el and mips32el-nf as their DEFAULTTUNEs, which your first patch, that got applied upstream, broke. But I've already switched to use your latest patch using mipsel and mipsel-nf instead, (which I prefer over the former).

Quoted 8 lines

Quoted 4 lines

My recommendation is either 2 or 3. The 3a/b variation is simply an implementation detail to me, and I will be happy to implement it either
way if this is the chosen direction.

I'm fine with either way that restores mips/mipsel for mips32 targets *before the release*, because the online update feeds broke and all packages had to be built again from scratch.

Quoted 6 lines

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I expect this to be corrected before the release, or should anybody relying on mipsel package feeds stop using oe-core's meta/conf/machine/include/mips/arch-mips.inc?

Sorry, I got distracted by a ton of other issues. I think the cleanup did make sense and things are more correct now, its just a shame about the package feed naming issue.

There comes a point we need to try and clean up some of these things so my proposal would be that people who don't want to use the new naming set the following in their distro config:

Quoted 8 lines

Quoted 4 lines

MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"

and then should still be able to use the arch-mips.inc from OE-Core. Does that work for people?

I wonder why this point has to be during the stabilisation phase before the release, considering much less intrusive changes are not getting applied.

This was a bug. That is why it was "fixed". I agree there is argument if this fix is acceptable or not, but it was a fix to a bug. We never should have been generating two tunings with different run-time characteristics on MIPS, with the same package arch.

Quoted 4 lines

Setting this variable is a partial workaround. PACKAGE_EXTRA_ARCHS also broke for tune-mips32.inc, so this has to be set, too. The easiest thing for everybody would however be to revert "Cleanup MIPS tunings to match README" and to drop tune-mips, which was unused.

Setting it to mips/mipsel should work as the PACKAGE_EXTRA_ARCHS in mips32 should already have "mips" or "mipsel" in them.

I would expect this would be a reasonable upgrade path as existing systems know only "mips".. so we rebuild with the custom "mips" setting, adding in the compatible extra_archs.. (hopefully adjusting the any feed management mechanisms at the same time).. And then for the "next" release the mips32 goes on line, and the system already knows it's compatible. [or the manual mips change suggested stays.]

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

Quoted 7 lines · Andreas Oberritter

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

How is this breaking opkg? We often have architectures listed in there for which there are no packages generated (all, noarch and any spring to mind)?

Quoted 9 lines · Richard Purdie

Quoted 7 lines · Andreas Oberritter

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

Quoted 3 lines

How is this breaking opkg? We often have architectures listed in there for which there are no packages generated (all, noarch and any spring to mind)?

Downloading http://10.0.0.1/mipsel/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
* opkg_download: Failed to download http://10.0.0.1/mipsel/Packages.gz, wget returned 1.

Quoted 9 lines · Richard Purdie

Quoted 7 lines · Andreas Oberritter

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

Quoted 3 lines

How is this breaking opkg? We often have architectures listed in there for which there are no packages generated (all, noarch and any spring to mind)?

Downloading http://10.0.0.1/mipsel/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
* opkg_download: Failed to download http://10.0.0.1/mipsel/Packages.gz, wget returned 1.

Quoted 10 lines · Andreas Oberritter

Quoted 9 lines · Richard Purdie

Quoted 7 lines · Andreas Oberritter

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

Quoted 8 lines

Quoted 3 lines

How is this breaking opkg? We often have architectures listed in there for which there are no packages generated (all, noarch and any spring to mind)?

Downloading http://10.0.0.1/mipsel/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
* opkg_download: Failed to download http://10.0.0.1/mipsel/Packages.gz, wget returned 1.

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 24 lines · Martin Jansa

Quoted 10 lines · Andreas Oberritter

Quoted 9 lines · Richard Purdie

Quoted 7 lines · Andreas Oberritter

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

Quoted 8 lines

Quoted 3 lines

How is this breaking opkg? We often have architectures listed in there for which there are no packages generated (all, noarch and any spring to mind)?

Downloading http://10.0.0.1/mipsel/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
* opkg_download: Failed to download http://10.0.0.1/mipsel/Packages.gz, wget returned 1.

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

Quoted 5 lines

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Quoted 24 lines · Andreas Oberritter

Quoted 10 lines · Richard Purdie

Quoted 9 lines · Andreas Oberritter

Quoted 7 lines

now, after having repacked all binary tarballs that had mipsel or mipsel-nf in their name and contents, and after having changed all occurrences of mipsel and mipsel-nf in my local recipes (where appropriate), and after having rebuilt everything from scratch again, it came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg, because no mipsel packages are being generated. That's what I told before, right?

Quoted 8 lines

Quoted 3 lines

How is this breaking opkg? We often have architectures listed in there for which there are no packages generated (all, noarch and any spring to mind)?

Downloading http://10.0.0.1/mipsel/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
* opkg_download: Failed to download http://10.0.0.1/mipsel/Packages.gz, wget returned 1.

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

Quoted 5 lines

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Quoted 11 lines · Richard Purdie

Quoted 9 lines · Martin Jansa

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

I don't think that's user-friendly and I don't know what's so bad about removing something that probably hasn't helped anybody.

Quoted 12 lines · Andreas Oberritter

Quoted 11 lines · Richard Purdie

Quoted 9 lines · Martin Jansa

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

Quoted 22 lines · Richard Purdie

Quoted 12 lines · Andreas Oberritter

Quoted 11 lines · Richard Purdie

Quoted 9 lines · Martin Jansa

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 8 lines

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

At least we should have defaults that actually work for someone. Now we don't and considering that distro-feed-configs.bb is the only place where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to accomplish. Especially because it worked well by default before Mark broke it.

I guess it's indeed better to just override the necessary bits in my distro instead of trying to get working defaults upstream.

Regards,
Andreas

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 32 lines · Andreas Oberritter

Quoted 22 lines · Richard Purdie

Quoted 12 lines · Andreas Oberritter

Quoted 11 lines · Richard Purdie

Quoted 9 lines · Martin Jansa

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 8 lines

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

Quoted 5 lines

At least we should have defaults that actually work for someone. Now we don't and considering that distro-feed-configs.bb is the only place where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to accomplish. Especially because it worked well by default before Mark broke it.

PACKAGE_EXTRA_ARCHS is also used by Zypper, RPM configuration and other places.
In those cases it is a full list of all available (and compatible) package
architecture types.

Coming from the RPM world, it seems very odd to me that a set of "extra_archs" can not list well, extra compatible archs without causing an error. I have no idea how to reconcile this behavior, without making a package manager distro-feed specific solution. (For RPM we absolutely want the existing behavior.)

Quoted 10 lines

I guess it's indeed better to just override the necessary bits in my distro instead of trying to get working defaults upstream.

Regards,
Andreas

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 39 lines · Andreas Oberritter

Quoted 32 lines · Richard Purdie

Quoted 22 lines · Andreas Oberritter

Quoted 12 lines · Richard Purdie

Quoted 11 lines · Martin Jansa

Quoted 9 lines

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 8 lines

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

Quoted 5 lines

At least we should have defaults that actually work for someone. Now we don't and considering that distro-feed-configs.bb is the only place where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to accomplish. Especially because it worked well by default before Mark broke it.

Quoted 8 lines

PACKAGE_EXTRA_ARCHS is also used by Zypper, RPM configuration and other places.
In those cases it is a full list of all available (and compatible) package
architecture types.

Coming from the RPM world, it seems very odd to me that a set of "extra_archs" can not list well, extra compatible archs without causing an error. I have no idea how to reconcile this behavior, without making a package manager distro-feed specific solution. (For RPM we absolutely want the existing behavior.)

The problem Andreas is seeing is not fatal AFAIK.. just couple (or a lot) of 404 (Packages files not available) while doing opkg update is not nice for end user.

Downloading many existing Packages files without any Package in it is also suboptimal, but maybe good start.. so we can teach meta/classes/package_ipk.bbclass:package_update_index_ipk() to create Packages files not only for existing ipkgarchs="${ALL_MULTILIB_PACKAGE_ARCHS} ${SDK_PACKAGE_ARCHS}" but for all (replace "if [ -e $pkgdir/ ]; then" with something like "if [ ! -e $pkgdir/ ]; then mkdir -p $pkgdir; fi")

Op 18 apr. 2012, om 17:46 heeft Martin Jansa het volgende geschreven:

Quoted 53 lines · Mark Hatle

Quoted 39 lines · Andreas Oberritter

Quoted 32 lines · Richard Purdie

Quoted 22 lines · Andreas Oberritter

Quoted 12 lines · Richard Purdie

Quoted 11 lines · Martin Jansa

Quoted 9 lines

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 8 lines

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

Quoted 5 lines

At least we should have defaults that actually work for someone. Now we don't and considering that distro-feed-configs.bb is the only place where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to accomplish. Especially because it worked well by default before Mark broke it.

Quoted 8 lines

PACKAGE_EXTRA_ARCHS is also used by Zypper, RPM configuration and other places.
In those cases it is a full list of all available (and compatible) package
architecture types.

Coming from the RPM world, it seems very odd to me that a set of "extra_archs" can not list well, extra compatible archs without causing an error. I have no idea how to reconcile this behavior, without making a package manager distro-feed specific solution. (For RPM we absolutely want the existing behavior.)

The problem Andreas is seeing is not fatal AFAIK.. just couple (or a lot) of 404 (Packages files not available) while doing opkg update is not nice for end user.

Quoted 7 lines

Downloading many existing Packages files without any Package in it is also suboptimal, but maybe good start.. so we can teach meta/classes/package_ipk.bbclass:package_update_index_ipk() to create Packages files not only for existing ipkgarchs="${ALL_MULTILIB_PACKAGE_ARCHS} ${SDK_PACKAGE_ARCHS}" but for all (replace "if [ -e $pkgdir/ ]; then" with something like "if [ ! -e $pkgdir/ ]; then mkdir -p $pkgdir; fi")

That implies you're exposing feeds straight from OE, which is a bad, bad idea.

Quoted 64 lines

Op 18 apr. 2012, om 17:46 heeft Martin Jansa het volgende geschreven:

Quoted 60 lines · Mark Hatle

Quoted 39 lines · Andreas Oberritter

Quoted 32 lines · Richard Purdie

Quoted 22 lines · Andreas Oberritter

Quoted 12 lines · Richard Purdie

Quoted 11 lines · Martin Jansa

Quoted 9 lines

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 8 lines

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

Quoted 5 lines

At least we should have defaults that actually work for someone. Now we don't and considering that distro-feed-configs.bb is the only place where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to accomplish. Especially because it worked well by default before Mark broke it.

Quoted 8 lines

PACKAGE_EXTRA_ARCHS is also used by Zypper, RPM configuration and other places. In those cases it is a full list of all available (and compatible) package architecture types.

Coming from the RPM world, it seems very odd to me that a set of "extra_archs" can not list well, extra compatible archs without causing an error. I have no idea how to reconcile this behavior, without making a package manager distro-feed specific solution. (For RPM we absolutely want the existing behavior.)

The problem Andreas is seeing is not fatal AFAIK.. just couple (or a lot) of 404 (Packages files not available) while doing opkg update is not nice for end user.

Downloading many existing Packages files without any Package in it is also suboptimal, but maybe good start.. so we can teach meta/classes/package_ipk.bbclass:package_update_index_ipk() to create Packages files not only for existing ipkgarchs="${ALL_MULTILIB_PACKAGE_ARCHS} ${SDK_PACKAGE_ARCHS}" but for all (replace "if [ -e $pkgdir/ ]; then" with something like "if [ ! -e $pkgdir/ ]; then mkdir -p $pkgdir; fi")

Quoted 1 line

That implies you're exposing feeds straight from OE, which is a bad, bad idea.

Can you please elaborate on why this is a bad idea?

Op 18 apr. 2012, om 17:46 heeft Martin Jansa het volgende geschreven:

Quoted 53 lines · Mark Hatle

Quoted 39 lines · Andreas Oberritter

Quoted 32 lines · Richard Purdie

Quoted 22 lines · Andreas Oberritter

Quoted 12 lines · Richard Purdie

Quoted 11 lines · Martin Jansa

Quoted 9 lines

I had a lot of those (e.g. because armv7a-vfp-neon was including 20 arm*feed.conf variants in /etc/opkg most of them empty - without Packages.gz).

So I've added "filter" to distro-feed-configs
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
to add only feeds I'm generating (and I also don't want armv5* packages installed on armv7a-vfp-neon target unless user explicitly adds armv5* feed).

Quoted 6 lines

Quoted 3 lines

This is the better solution. I think we need to get a better default feed-config generation mechanism into the core. Distros may still need to tweak it but it would be good to share some of the best practises...

Did you look at the patch? Which default setting of SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

Quoted 8 lines

Quoted 4 lines

Do you think it's feasible to add
every single downloadable arch to this variable? If a user of my distro decides to build it for some arm or x86 cpu, should he need to know which archs to add at this place?

This is a place where the build system meets and interfaces with the distro. No one policy in the build system is going to fit every distro's needs, not should we ever aim to so.

Quoted 5 lines

At least we should have defaults that actually work for someone. Now we don't and considering that distro-feed-configs.bb is the only place where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to accomplish. Especially because it worked well by default before Mark broke it.

Quoted 8 lines

PACKAGE_EXTRA_ARCHS is also used by Zypper, RPM configuration and other places.
In those cases it is a full list of all available (and compatible) package
architecture types.

Coming from the RPM world, it seems very odd to me that a set of "extra_archs" can not list well, extra compatible archs without causing an error. I have no idea how to reconcile this behavior, without making a package manager distro-feed specific solution. (For RPM we absolutely want the existing behavior.)

The problem Andreas is seeing is not fatal AFAIK.. just couple (or a lot) of 404 (Packages files not available) while doing opkg update is not nice for end user.

Quoted 7 lines

Downloading many existing Packages files without any Package in it is also suboptimal, but maybe good start.. so we can teach meta/classes/package_ipk.bbclass:package_update_index_ipk() to create Packages files not only for existing ipkgarchs="${ALL_MULTILIB_PACKAGE_ARCHS} ${SDK_PACKAGE_ARCHS}" but for all (replace "if [ -e $pkgdir/ ]; then" with something like "if [ ! -e $pkgdir/ ]; then mkdir -p $pkgdir; fi")

That implies you're exposing feeds straight from OE, which is a bad, bad idea.