On Fri, Oct 25, 2024 at 05:11:31PM -0700, Andrew Morton wrote:
On Thu, 24 Oct 2024 08:25:46 +0100 Lorenzo Stoakes lorenzo.stoakes@oracle.com wrote:
I actually do plan to extend this work to support shmem and file-backed mappings in the future as a revision to this work.
Useful, thanks. I pasted this in.
(generally, it would be nice to include the proposed manpage update at this time, so people can review it while the code change is fresh in their minds)
It'd be nice to have the man pages live somewhere within the kernel so we can do this as part of the patch change as things evolve during review, but obviously moving things about like that is out of scope for this discussion :)
Yes, that would be good. At present the linkage is so poor that things could get lost.
Things _have_ got lost. I don't see MADV_DONTNEED_LOCKED in the madvise() man page for instance...
(I intend actually to send a patch for that alongside my changes.)
I guess one thing we could do is to include the proposed manpage update within the changelogs. That way it's stored somewhere and gets reviewed alongside the patches themselves.
Hm it won't be a diff but I do like the idea... let me come up with something.
I do explicitly intend to send a manpage update once this series lands however.
That's late, IMO. Sometimes reviewing manpage updates leads people to ask "hey. what about X" or "hey, that's wrong". Michael Kerrisk was good at finding such holes, back in the day.
Right, this is the problem with having the manpages in a separate repo, it seems presumptious to _assume_ this will land in 6.13 though I hope it does, but if I get a patch accepted in the manpages they may ship a version that has information that is simply invalid...
Really would be nice to integrate it here :)
Michael Kerrisk is a hero, writes with a power of clarity I could only dream of :) understandable that he may be rather tired of having to maintain all this however...