[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66c4d3ce4c6f47d29bbb951739555eb0@intel.com>
Date: Thu, 30 Jun 2022 16:07:29 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Bae, Chang Seok" <chang.seok.bae@...el.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Brown, Len" <len.brown@...el.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>
CC: "corbet@....net" <corbet@....net>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 1/1] Documentation/x86: Add the AMX enabling example
> But these state components are architectural. While this can help
> userspace anyway, saying "XSTATE component" here and on the man-page is
> probably it as they are already defined in the x86 spec.
An application writer can't use:
# include {x86 spec}"
to get these values ... if applications need them to find out if AMX is present,
and to enable it, then they need an API.
Maybe your example code should just be a library routine? So application writers
can just do:
if (!intel_amx_enable()) {
error message, or fall back to non-AMX implementation
}
without having to worry about those #defines.
-Tony
Powered by blists - more mailing lists