Solaris

This is Solaris... so NO... there's no way to extract such data reliably. The concepts of "family", "model" (the numeric x86 style value) and "stepping" do not apply to all processor types. There is no reliable way to get the cache information, and besides as processors now come with L1, L2 AND now L3 cache... which cache is interesting? Typically, other systems focus on L2 cache (I guess never believing that there would ever be L3).

You HAVE been guided, you've given enough info to get you started... but you're asking for things that either are n/a to Solaris/SPARC or just simply cannot be retrieved easily.

If you want that kind of CPU data on Solaris Intel, new Solaris revisions will contain the smbios command which is like the dmidecode utility under Linux and you should be able to get most of what you are wanting CPU wise from that.... but it's not going to work on SPARC platforms. Also, I'll just point out that Solaris smbios command is NOT nearly as good as dmidecode... so you might just want to build and compile dmidecode and run it on your Intel Solaris boxes... THEN you will get everything, including Family, Model, Stepping. Dmidecode will show you L1, L2 and L3 cache data as well... and it does compile quite well on Solaris Intel.... not sure why they went with their own smbios tool (??) it's a very poor replacement. And you won't find smbios except on the NEWEST Solaris... not even sure if it's any Solaris 10.

smbios has been available on Solaris 10 for a while now.

I couldn't remember if it was something I added or not... thanks... it still stinks in comparison to dmidecode though.

Interesting disagreeing opinion in its announcement (Aug 2005): Heads up: x86 SMBIOS Support (Community Group on.2005082701) - XWiki

If you've used Linux "dmidecode" before, this is the same idea, but hopefully a more useful and friendly implementation.

Try kstat -m cpu_info, and see if the CPU info you are looking for is in there,....

Maybe I missed something. Typical Sun/Solaris rah-rah we're number one and we don't need to really look at somebody else's work (sigh). Smbios, it's like dmidecode, except it doesn't really decode everything :-)

What do I know... I just use the tools and compare... one works and the other does not. It's really NOT an opinion issue.. maybe someday, smbios will catch up... the world just wonders why it exists. The links is from 2005, yes, the crapola smbios that is in Solaris 10 essentially.... again, the question "why" keeps coming to mind. Ditto for Microsoft.... of course they are even worse, they pull in the smbios data, make it available in a "manner" but don't attempt to interpret the data at all..... which makes some of their WMI data almost laughable because it is so far off. Not saying that all SMBios data is good, but it's better than what a lot of people use for data sources.

I don't get your rant. I would assume that when Solaris smbios code started to be developed, dmidecode wasn't providing the features Solaris engineering was expecting.
I'm also afraid you are overreacting/exaggerating by writing "smbios stinks, is NOT nearly as good ..., doesn't work." Smbios is fine enough for most if not all needs. If you have specific bugs or enhancements you would like to seen fixed, then please express them clearly.