On Tue, Dec 4, 2018 at 10:24 AM Jerome Glisse <jglisse@xxxxxxxxxx> 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. That sounds needlessly restrictive. Let the kernel arbitrate what memory an application gets, don't design a system where applications are hard coded to a memory type. Applications can hint, or optionally specify an override and the kernel can react accordingly.