On Tue, Nov 10, 2020 at 09:37:12AM +0100, Karel Zak wrote: > On Mon, Nov 09, 2020 at 11:19:08PM -0600, Jeremy Linton wrote: > > I don't agree with this, I think the hard coded table should be the first > > authority on the manufacture/part number lists. That is because SMBIOS isn't > > available on a fairly large number of arm systems, and on systems where it > > does exist, it suffers from the same kinds of problems that exist on many > > !arm machines. Its not particularly a reliable source of information. > > > > So, maybe if you have a situation where the SMBIOS information is more > > correct than the hardcoded tables, maybe its a good idea to create a new > > line? > > > > > > Aka: > > > > Vendor Id: ARM > > Model Name: Cortex-A57 > > BIOS Name: JoeSmithsCore > > I like this idea. Yeah, it's s great idea! SMBIOS Type4 also has Vendor Id (Processor Manufacturer), so the following is better? Vendor Id: ARM Model Name: Cortex-A57 BIOS Vendor Id: Foobar BIOS Model Name: JoeSmithsCore Jeff, does the above idea work for your case? X-Gene(eMAG) will be: Vendor Id: APM Model Name: X-Gene BIOS Vendor Id: Ampere(TM) BIOS Model Name: eMAG Thanks, Masa > > Note that for majority of our users know, use and expect names like > Cortex-A57, but I have doubts about "JoeSmithsCore" :-) > > > In the vast majority of cases I imagine the strings should match. The > > problematic cases are LTS os's running on newer hardware. For that i'm > > somewhat of the opinion the Model Name should remain "unknown" rather than > > being silently updated. That is to avoid cases where the output from newer > > lscpu's changes during an upgrade. > > > > PS, Having this hardcoded table isn't optimal, but for now I think we are > > stuck with it. Hopefully at some point we can work out a reliable way to > > source the info. In the meantime, it looks like I need to submit some table > > updates, since there are some newer arm models... > > Yes. > > Karel > > -- > Karel Zak <kzak@xxxxxxxxxx> > http://karelzak.blogspot.com >
