On 12/4/18 11:54 PM, Jerome Glisse wrote:
On Tue, Dec 04, 2018 at 09:06:59AM -0800, Andi Kleen wrote:
jglisse@xxxxxxxxxx writes:
+
+To help with forward compatibility each object as a version value and
+it is mandatory for user space to only use target or initiator with
+version supported by the user space. For instance if user space only
+knows about what version 1 means and sees a target with version 2 then
+the user space must ignore that target as if it does not exist.
So once v2 is introduced all applications that only support v1 break.
That seems very un-Linux and will break Linus' "do not break existing
applications" rule.
The standard approach that if you add something incompatible is to
add new field, but keep the old ones.
No that's not how it is suppose to work. So let says it is 2018 and you
have v1 memory (like your regular main DDR memory for instance) then it
will always be expose a v1 memory.
Fast forward 2020 and you have this new type of memory that is not cache
coherent and you want to expose this to userspace through HMS. What you
do is a kernel patch that introduce the v2 type for target and define a
set of new sysfs file to describe what v2 is. On this new computer you
report your usual main memory as v1 and your new memory as v2.
So the application that only knew about v1 will keep using any v1 memory
on your new platform but it will not use any of the new memory v2 which
is what you want to happen. You do not have to break existing application
while allowing to add new type of memory.
So the knowledge that v1 is coherent and v2 is non-coherent is within
the application? That seems really complicated from application point of
view. Rill that v1 and v2 definition be arch and system dependent?
if we want to encode properties of a target and initiator we should do
that as files within these directory. Something like 'is_cache_coherent'
in the target director can be used to identify whether the target is
cache coherent or not?
-aneesh
