> >Should we schedule the removal of this interface after 1-2 releases >and give a warning once if anybody opens /dev/oldmem and tell them >to use /proc/vmcore instead? How can anyone use /dev/oldmem correctly? To the best of my knowledge there are no parsers of the ELF header passed by /sbin/kexec in userspace. If there is anyone who cares they can complain and we can revert the removal. All of the evidence is that everyone uses /proc/vmcore. >I am kind of inclined towards warning approarch. If there is any xyz >/dev/oldmem user in the wild out there, he/she atleast gets a chance to >migrate to /proc/vmcore. If there is a user out there that does not choose to participate in the community, or pay someone to participate on their behalf, it saddens me but I don't care. All someone has to do is to keep a weather eye on the kexec mailing list, the linux kernel mailing list or simply run a test kernel, and tell us that they use /dev/oldmem. That is grounds under the no regression rule for a revert. At a practical level a user who does not care will likely be using a frozen kernel and won't notice until they finally decide to upgrade their kernel, in several years time. I don't think we should carry an apparently dead interface around for the next five years on the off chance someone uses it. Especially with no users and no one who cares we won't maintain the interface properly and it will bit rot and be broken. Which means if there is someone using /dev/oldmem we have a choice of what to do in 5 years time when someone notices. - Field a bug report about someones kdump implementation acting weird. - Deal with a report of someones kdump implementation not working because /dev/oldmem is gone. With /dev/oldmem gone at least we will be able to get to the root cause of the problem. -ENODEV. Which is a long way of saying this is the time for anyone who uses /dev/oldmem to speak now or forever hold their piece. Eric
