On Tue, Mar 29, 2022 at 05:46:49PM -0700, Darrick J. Wong wrote:
> On Wed, Mar 30, 2022 at 11:34:57AM +1100, Dave Chinner wrote:
> > I see no statement anywhere about what this printk index ABI
> > requires in terms of code stablility, format string maintenance and
> > modification, etc. I've seen it referred to as "semi-stable" but
> > there is no clear, easily accessible definition as to what that
> > means for either kernel developers or userspace app developers that
> > might want to use this information. There's zero information
> > available about how userspace will use this information, too, so at
> > this point I can't even guess what the policy for this new ABI
> > actually is.
> >
> > If this was discussed and a policy was created, then great. But it
> > *hasn't been documented* for the rest of the world to be able to
> > read and understand so they know how to deal safely with the
> > information this ABI now provides. So, can you please explain what
> > the rules are, and then please write some documentation for the
> > kernel admin guide defining the user ABI for application writers and
> > what guarantees the kernel provides them with about the contents of
> > this ABI.
>
> FWIW if you /did/ accept this for 5.19, I would suggest adding:
>
> printk_index_subsys_emit("XFS log messages shall not be considered a stable kernel ABI as they can change at any time");
>
> I base that largely on the evidence -- there's nothing saying that
> catalogued strings are or are not a stable ABI. That means it's up to
> the subsystem or the maintainers or whoever to make a decision, and I
Yup, that's largely what I want clarified before we make a
decision one way or another. There must have been some discussion
and decisions on what the policy is before it was merged, but it's
not easily findable.
And, IMO, instead of every single subsystem having to go through the
same question and answer process as we are currently doing, I want
that policy to be documented such that a simple "git grep
printk_index_subsys_emit" search returns the file in the
Documentation/ directory that explains all this. That makes
everyone's lives a whole lot easier.
> would decide that while some people somewhere might benefit from having
> the message catalogue over not having it (e.g. i18n), someone would have
> to show a /very/ strong case for letting XFS get powertop'd.
Yeah, I'd push back very hard against that, too, but in the absence
of any documentation defining the contract to either the kernel or
userspace application developers, it's impossible to know where we
stand to begin with. I much prefer to be able to quote letter and
verse of the documentation than to have to repeatedly justify why
we consider the (un)documented policy to be broken....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
