On Wed 2022-03-30 12:26:24, Dave Chinner wrote:
> 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.
I understand this fear. It was my very first reaction on the printk
index feature as well.
Chris explained to me that it is exactly the opposite. I have tried to
summarize my undestanding in the following RFC patch. I could
send it separately for a proper review if you agree that
this is the right way to go.
I think that we will actually need to extend the section about
the subsystem specific prefix. It seems that Chris has another
opinion based on his real life experience with this feature.
Anyway, I send this draft now. It is getting late here. I hope
that it will answer some questions...
Here we go:
