On 04.12.18 10:44, Michal Suchánek wrote: > On Fri, 30 Nov 2018 18:59:21 +0100 > David Hildenbrand <david@xxxxxxxxxx> wrote: > >> Let's introduce new types for different kinds of memory blocks and use >> them in existing code. As I don't see an easy way to split this up, >> do it in one hunk for now. >> >> acpi: >> Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel. >> Properly change the type when trying to add memory that was already >> detected and used during boot (so this memory will correctly end up as >> "acpi" in user space). >> >> pseries: >> Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel. >> As far as I see, handling like in the acpi case for existing blocks is >> not required. >> >> probed memory from user space: >> Use DIMM_UNREMOVABLE as there is no interface to get rid of this code >> again. >> >> hv_balloon,xen/balloon: >> Use BALLOON. As simple as that :) >> >> s390x/sclp: >> Use a dedicated type S390X_STANDBY as this type of memory and it's >> semantics are very s390x specific. >> >> powernv/memtrace: >> Only allow to use BOOT memory for memtrace. I consider this code in >> general dangerous, but we have to keep it working ... most probably just >> a debug feature. > > I don't think it should be arbitrarily restricted like that. > Well code that "randomly" offlines/onlines/removes/adds memory blocks that it does not own (hint: nobody else in the kernel does that), should be restricted to types we can guarantee to work. > Thanks > > Michal > -- Thanks, David / dhildenb _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
