Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys_device ?

[David Hildenbrand]

>> Otherwise, hot(un)plugging smaller granularity behaves more like memory
>> ballooning (and I think I don't have to tell you that ballooning is used
>> excessively even though it wastes memory on metadata ;) ). Anyhow,
>> that's another discussion.
> 
> Yeah, I am aware of that. And honestly subsection offlining makes very
> little sense to me. It was hard to argue against that for nvdimm
> usecases where we simply had to workaround the reality where devices
> couldn't have been aligned properly. I do not think we want to claim a
> support for general hotplug though. 

Totally agree, I also don't want to see actual sub-section
onlining/offlining in the core (e.g., virtio-mem emulates that on top,
but it behaves a lot more like memory ballooning).

> 
> [...]
> 
>>> There is only one certainty. Providing a long term interface with ever
>>> growing (ab)users is a hard target. And shinyN might be needed in the
>>> end. Who knows. My main point is that the existing interface is hitting
>>> a wall on usecases which _do_not_care_ about memory hotplug. And that is
>>> something we should be looking at.
>>
>> Agreed. I can see 3 scenarios
>>
>> a) no memory hotplug support, no sysfs.
>> b) memory hotplug support, no sysfs
>> c) memory hotplug support, sysfs
>>
>> Starting with a) and c) is the easiest way to go.
> 
> Yes, the first and the simplest way would be to provide
> memory_hotplug=[disabled|v1]
> 
> where disabled would be no sysfs interface, v1 would be the existing
> infrastructure. I would hope to land with v2 in a future which would
> provide a new interface.
> 

Agreed.

-- 
Thanks,

David / dhildenb