On Wed, 30 Mar 2022 12:54:13 -0400 (EDT) Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > ----- On Mar 29, 2022, at 10:25 PM, rostedt rostedt@xxxxxxxxxxx wrote: > > > From: "Steven Rostedt (Google)" <rostedt@xxxxxxxxxxx> > > > > After being merged, user_events become more visible to a wider audience > > that have concerns with the current API. It is too late to fix this for > > this release, but instead of a full revert, just mark it as BROKEN (which > > prevents it from being selected in make config). Then we can work finding > > a better API. If that fails, then it will need to be completely reverted. > > Hi Steven, > > What are the constraints for changing a uapi header after it has been present > in a kernel release ? > > If we are not ready to commit to an ABI, perhaps it would be safer to ensure > that include/uapi/linux/user_events.h is not installed with the uapi headers > until it's ready. > Linus may say otherwise, but from what I understand is that we can not break a user space application from one release to the next. That means, the only way to break something is if it is actually using something in binary form. I can not think of a situation where a header file is useful if the API it's used for is not available. Thus do we really need to hide it? What applications will use a header file that has no interface for it? I do not see the need to remove the uapi if the API for that structure is not available yet. -- Steve
