On Wed, May 08, 2019 at 10:34:44AM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > On Mon, May 06, 2019 at 01:53:28PM +0200, Markus Armbruster wrote: > >> Eduardo Habkost <ehabk...@redhat.com> writes: > >> > >> > This series adds a new CPUClass::class_name_format field, which > >> > allows us to delete 16 of the 21 *_cpu_class_by_name() functions > >> > that exist today. > >> > >> Which five remain, and why? > > > > alpha_cpu_class_by_name: > > * Translates aliases based on alpha_cpu_aliases; > > * Falls back to "ev67" unconditionally > > (there's a "TODO: remove match everything nonsense" comment). > > > > cris_cpu_class_by_name: > > * Translates "any" alias to "crisv32" if CONFIG_USER_ONLY. > > > > ppc_cpu_class_by_name: > > * Supports lookup by PVR if CPU model is a 8 digit hex number; > > * Converts CPU model to lowercase. > > > > superh_cpu_class_by_name: > > * Translates "any" alias to TYPE_SH7750R_CPU. > > > > sparc_cpu_class_by_name: > > * Replaces whitespaces with '-' on CPU model name. > > I'm of course asking because I wonder whether we can dumb down this CPU > naming business to something simpler and more regular.
We can, but that's not on my list of priorities. Any volunteers? > [...] > * Aliases > > We have several targets roll their own CPU name aliases code. > Assuming aliases are here to stay (i.e. we're not deprecating all of > them): what about letting each CPU type specify a set of aliases, so > we can recognize them in generic code? Yes. I considered adding alias support to generic code, but decided to do this one step at a time. -- Eduardo