On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > There is a large number of Arm Tune files located in > meta/conf/machine/include/, and to support the current and upcoming Arm > cores, more are needed. Adding more files is simply going to make it > harder to find the relevant ones for an OE/YP developer/user. Also, > there are problems with stale and erroneous configs (see my previous > series), which will only be exacerbated by having more files. > > I am proposing a reorganization of the existing tune files by including > them in the generic family include file. For example, the > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > tune-cortexa57.inc would be moved into arch-armv8a.inc. This reduces > the number of files from 12 to 2 for ARMv8a, and that is excluding the > 13 I am adding in this series that would otherwise be unique files. > > To use, simply add > ... > DEFAULTTUNE ?= "neoversen1" > require conf/machine/include/arm/arch-armv8-2a.inc > ... > > Which is arguably what should be done anyway (instead of taking the > default of the tune include file). > See the qemuarm64 patch in the series for a working example. > > Of course, by removing the existing tune files, current users are going > to break. A simple script can be written to use sed (or similar) to > replace the relevant parts for those users that would be affected (at > least for those that are in the layer index and update regularly).
I've just looked at this in a bit more details and I'm worried. The intent is the BSP includes the processor/core tune file that its based upon. The BSP should usually know which one is present. That tune then presents the possible options which the BSPs selects from but the end user or distro can override. With this change, you get all tunes and you don't know which are compatible with a given core/processor. I'm not sure that is an improvement. I appreciate not wanting "lots of files" but we need to consider the usability too. As others have mentioned, the errors are fairly obvious with diff between the files (or a GUI like meld). What are the advantages this brings other than fewer files? Am I missing something? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142610): https://lists.openembedded.org/g/openembedded-core/message/142610 Mute This Topic: https://lists.openembedded.org/mt/76844469/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
