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. > +2) hbind() bind range of virtual address to heterogeneous memory > +================================================================ > + > +So instead of using a bitmap, hbind() take an array of uid and each uid > +is a unique memory target inside the new memory topology description. You didn't define what an uid is? user id? Please use sensible terminology that doesn't conflict with existing usages. I assume it's some kind of number that identifies a node in your graph. > +User space also provide an array of modifiers. Modifier can be seen as > +the flags parameter of mbind() but here we use an array so that user > +space can not only supply a modifier but also value with it. This should > +allow the API to grow more features in the future. Kernel should return > +-EINVAL if it is provided with an unkown modifier and just ignore the > +call all together, forcing the user space to restrict itself to modifier > +supported by the kernel it is running on (i know i am dreaming about well > +behave user space). It sounds like you're trying to define a system call with built in ioctl? Is that really a good idea? If you need ioctl you know where to find it. Please don't over design APIs like this. > +3) Tracking and applying heterogeneous memory policies > +====================================================== > + > +Current memory policy infrastructure is node oriented, instead of > +changing that and risking breakage and regression HMS adds a new > +heterogeneous policy tracking infra-structure. The expectation is > +that existing application can keep using mbind() and all existing > +infrastructure under-disturb and unaffected, while new application > +will use the new API and should avoid mix and matching both (as they > +can achieve the same thing with the new API). I think we need a stronger motivation to define a completely parallel and somewhat redundant infrastructure. What breakage are you worried about? The obvious alternative would of course be to add some extra enumeration to the existing nodes. It's a strange document. It goes from very high level to low level with nothing inbetween. I think you need a lot more details in the middle, in particularly how these new interfaces should be used. For example how should an application know how to look for a specific type of device? How is an automated tool supposed to use the enumeration? etc. -Andi
