[PATCH 0/7] Remove unused /dev/oldmem interface

[Eric W. Biederman]

>
>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