>> There were once RFC patches to make use of it in ACPI, but it could be >> solved using different interfaces [1]. >> >> >> While I'd love to rip it out completely, I think it would break old >> lsmem/chmem completely - and I assume that's not acceptable. I was >> wondering what would be considered safe to do now/in the future: >> >> 1. Make it always return 0 (just as if "sclp.rzm" would be set to 0 on >> s390x). This will make old lsmem/chmem behave differently after >> switching to a new kernel, like if sclp.rzm would not be set by HW - >> AFAIU, it will assume all memory is in a single memory increment. Do we >> care? > > No, at least not until that kernel change would be backported to some > old distribution level where we still use lsmem/chmem from s390-tools. > Given that this is just some clean-up w/o any functional benefit, and > hopefully w/o any negative impact, I think we can safely assume that no > distributor will do that "just for fun". > > Even if there would be good reasons for backports, then I guess we also > have good reasons for backporting / switching to the util-linux version > of lsmem / chmem for such distribution levels. Alternatively, adjust the > s390-tools lsmem / chmem there. > > But I would rather "rip it out completely" than just return 0. You'd > need some lsmem / chmem changes anyway, at least in case this would > ever be backported. Thanks for your input Gerald. So unless people would be running shiny new kernels on older distributions it shouldn't be a problem (and I don't think we care too much about something like that). I don't expect something like that to get backported - there is absolutely no reason to do so IMHO. > >> 2. Restrict it to s390x only. It always returned 0 on other >> architectures, I was not able to find any user. >> >> I think 2 should be safe to do (never used on other archs). I do wonder >> what the feelings are about 1. > > Please don't add any s390-specific workarounds here, that does not > really sound like a clean-up, rather the opposite. People seem to have different opinions here. I'm happy as long as we can get rid of it (either now, or in the future with a new model). > > That being said, I do not really see the benefit of this change at > all. As Michal mentioned, there really should be some more fundamental > change. And from the rest of this thread, it also seems that phys_device > usage might not be the biggest issue here. > As I already expressed, I am more of a friend of small, incremental changes than having a single big world switch where everything will be shiny and perfect. (Deprecating it now - in any way - stops any new users from appearing - both, in the kernel and from user space - eventually making the big world switch later a little easier because there is one thing less that vanished) -- Thanks, David / dhildenb
