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@xxxxxxxxxx> 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...
