> Regardless of removal, i'd suggest a "this code is not supported" kind of > WARN() message to the APM code today, into .39 - to see whether it pops up > anywhere - and mark it for -stable as well. Okay, can do. > .42 removal might be too fast, considering the typical release schedule of > Linux distributions. And i'm still doubting the removal itself: we are adding > lots of special-purpose subarch drivers to arch/x86/ as we speak (the embedded > mess coming to x86) - which drivers will be tomorrow's APM code. On what > grounds do we treat APM support differently? > > Our general compatibility with old hardware is an *asset* that we should value. My guess is that the customers have died off, and so the code is no longer an asset, but a maintenance liability. If there is a buzzing community of people running 2011 linux kernels on their ancient laptops in APM mode, then the APM maintainer would probably know about them. Personally, my oldest usable laptop is a T23 from March 2002. It supports APM and ACPI (it shipped with Win2K). Linux works well on it in ACPI mode, but doesn't even boot in APM mode. If anybody was really using the latest kernel in APM mode, I suspect this laptop would boot... Is there somebody on LKML that has a older laptop than me and is able to get it to boot in APM mode? I'd be astonished if there was not. Are they willing to regularly test changes to the upstream kernel to make sure that APM still works? If yes, where have they been for the last 5 years? I suspect when there is nobody using the latest kernel on mrst, then the latest kernel can delete support for mrst, and nobody will care. Like APM, it will probably undergo "maintenance without testing", aka bit rot, for a period before that happens. cheers, -Len _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
