On Thu, Feb 14, 2013 at 9:24 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 15 Feb 2013 04:42:27 +0100 Martin Sustrik <sustrik@xxxxxxxxxx> wrote: > >> > This is a non-back-compatible userspace interface change. A procfs >> > file which previously displayed >> > >> > eventfd-count: nnnn >> > >> > can now also display >> > >> > eventfd-mask: nnnn >> > >> > So existing userspace could misbehave. >> > >> > Please fully describe the proposed interface change in the changelog. >> > That description should include the full pathname of the procfs file >> > and example before-and-after output and a discussion of whether and why >> > the risk to existing userspace is acceptable. >> >> I am not sure what the policy is here. Is not printing out the state of >> the object acceptable way to maintain backward compatibility? If not so, >> does new type of object require new procfs file, which, AFAIU, is the >> only way to retain full backward compatibility? > > Adding a new file is the only way I can think of to preserve the API. > But from Andy's comment is sounds like we don't have to worry a lot > about back-compatibility. > I'm not even convinced there's an issue in the first place (other than the fact that use of this feature will break old criu, regardless of /proc changes). The fdinfo files already vary by descriptor type. Anything that screws up if unexpected fields are present is already screwed. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
