 So we did some huge progress last year, maybe you put out the table of contents. I've added like half a chapter, and that's pretty much all we have. So ideas, anybody? John? Ideas, you guys should all write some more stuff. I thank you very much. I mean, what we're seeing of course is the problem we see across the entire kernel. We have thousands of people paid to work on the kernel, we have zero people paid to work on documentation. And we see the results of that. I don't know what to do other than to complain to our employers and try to get some resources attached to that. I'm sure that's an easy thing to do. It isn't an easy thing to do. I can start pointing to people, hey, you have to do this and that, but it won't work anyway. I have to say what I found is at various different companies, not just my current employer, when you talk to management and say, hey, we need documentation, people are like, yeah, but I can only get funding to hire engineers, I can't get funding to hire documentation people. So there's some corporate brokenness that seems endemic to our industry. You're an engineering manager, you're not a documentation manager. It's like, how do we ever produce documentation for other products? One thing I think could be possible and something I've been trying to enforce a little bit is you don't accept patches unless it's documented. That's a requirement. And then you might get employers to fund it. But we have a huge debt. Well, I know, but then what you could do is actually kind of like say, okay, we'll take this patch if you document that. We should have taken Maple three after Liam would document the chapter of the process memory. Yeah, exactly. That's good, yeah. That's how the Futex people got the Futex 2 working because it was like, can you modify Futex? I said, no, you have to rewrite a whole new Futex infrastructure to get this feature in. So the problem is not every engineer is a good writer. Well, I kind of volunteered to help with that. Yes. But the second comment I want to make is that, like, yes, it looks like it's endemic to our field. So maybe we should have, like, maybe this is like good projects for outreach or something to add documentation to MM. It will be really tough for outreach, you know. To understand what you're writing about. I don't know, Lorenzo, how much did it take you to start the book? Oh, but following Steve's suggestions, I think we can't remove SLAP before the stimulus documents loop. As someone who contributed to Google Summer of Code, which is very close to our treat as far as I know, and I think it's not ideal at all to have people through outreach or Google Summer of Code or even interns do that work. When I was an intern at Google, if someone told me here, I'm going to work for three months in documenting some things no one wanted to document, I would be... You wouldn't buy it. Yeah, that would be a very poor internship experience. I don't think we should delegate this to... No. And unfortunately... Our treat is not exactly internship. It is internship. It's pretty much like Google Summer of Code, yes. It's not exactly because people can be from different backgrounds. Like, they don't have to be, like, specialized. But essentially, I mentored several projects in outreach. They come with a fresh graduate level of expertise. So if you ask them to document, let's say, how process manages its memory, it will take them like three outreach rounds to get there. So the question is, how do we solve this endemic problem in our field? How can we find... That's what I'm asking the audience, sir. How can we find people who are good at documenting and... May I say this is good at documenting? Joan. Well, actually, I wanted to point out to our esteemed scribe that we had an offer, last plumbers, from someone who was actually a professional documenter, and then we just never followed up. We completely dropped the ball on that. I don't remember that, but... Yeah, it was a plumbers. We had a documentation session and a lady called in, who I haven't known personally, and we've pinged a couple of times, and we've just never got around to having the kickoff meeting. So this part of it is on us, but I will resend the ping, John, and maybe this time we'll actually have the kickoff meeting. Yeah, I have actually talked to the person involved a couple of times, and it never seems to really go very far. Another try is worth doing. But in terms of finding people somewhere, if you can find good writers, you can write about this stuff. They're not gonna do... Mermi managed a different documentation, because I'll hire them. I mean, it's hard. It's really hard to find people who can do this well. But it's hard to find good engineers, and we work to bring them up to speed over time. I think we should be able to do the same with writers. Yeah, he's saying the outreach... So my point is that with outreach, people choose what they want to work on. It's not like they join, and then they are given a project. They pick a project out of a list of projects, and if there is someone comes who wants to write a documentation, who feels that they actually can help, why ignore them? Well, I can propose a Merm documentation as outreach project next year. We'll see if there will be any buyers. And can you please give... I can see there's something called Google Season of Docs, which says Google Season of Docs provides support for open-source projects to improve their documentation and gives professional technical writers an opportunity to... That's where it ends, but... Don't you be participating in that sometime? So probably it could work, yes. It's called Google Season of Docs, and it's exactly what we're talking about. Yeah. And these are people signing... Technical writers signing up to write technical documentation. So I feel... Obviously, I've got some thoughts on this. I think that you have to be an engineer at the same time as a documenter. You just have to have that depth. I mean, or at least collaborate with an engineer, perhaps. Because I'm finding that in order to explain it clearly, I've really got to go into the code and do the engineering side. And it's kind of like a... The two things are tied together, I think. So if we go back to the team of companies, wouldn't pay for it. What I noticed is that companies do like to have nice blocks. For example, I have recently seen some block series on SLAP, on Oracle block, I guess. So it would be great here. I guess they do it for promotion, but if they could also sell some condensed version contribute of that block to the documentation, that would be a way. I'd be even ready to take their block, but I suspect there will be legal implications. Not the Oracle one. If it doesn't already say it's GFTL licensed or something, ping me, I will get it re-licensed for suitable use inside the kernel. That's anything on Oracle's blog. So for example, I've already committed to it on the mailing list, but I now actually have a task to do some documentation for reclaim, and I do plan to contribute it to the kernel documentation as well, as well as a SUSE block or something. So if you happen to write a SUSE blog, redhead blog, Google blog or whatever, you can just send me a pointer because I'm not really following. I'll try to put it in the documentation, a memo, whatever. No. I think this must be a crazy idea, but what do you think about just using chatJPT for writing the first draft of the document? I mean, maybe there could be some license issue or some complex things. However, if we agree that having something is better than nothing, and if that could be used as just a first draft that just letting others to start fixing, maybe we can do that without merging that inside the mainline, but using some kind of work in progress tree. I would say to that, just try asking chatJPT about the kernel, and you'll get your answer for why. It's probably will be harder to review what chatJPT has written than to write your own documentation. Somebody puts on my site the results of asking chatJPT to describe in the style of LWN, the debate over incorporating Python into the Linux kernel. It was very authoritative on it, right? I mean, I don't see that as a way with the current state of the tools at least to make life easier. It's a way to, at best, put in really subtle errors. And speaking of Google Summer of Documentation, or Google Season of Documentation and the Outreach, there is something that we as a community should be ready to do is to review what they have written. And to address and to provide productive feedback and not usual now. So it will be some, even if there will be people who will buy into the documentation season, it will be up to us to help them with that. I'm just assuming that we ask chatJPT to produce documentation that Linux kernel is going to spit Mel's book back at us. So how big of a problem like when someone sends a doc change page and no reviewers, is that a bigger, I mean, I get very few standalone documentation patches, but generally the Randy will come in and check the text and whoever wrote the code will hopefully take a look, but no, it happens very rarely. I couldn't give a general answer to that. One thing I noticed with the recent documentation patch that went in is it was very, there's a lot of nitpicking going on. And it took forever for this very small bit of text to go in. And I wonder whether that's just gonna make the pace glassy or for getting anything in on docs. It's kind of the ultimate thing to bike shed as well. Yeah, doc is not code. So it shouldn't be so picky. And it's better to have some doc instead of having no doc. And if someone has like a lot of changes, maybe accept it first and then send a followup patch to fix those changes in the doc. It would help me greatly if when we have specific very nitpicky reviewers of documentation, if we could simply tell them this documentation is good enough, that happened with, I believe in memory management doc recently where people just had to intervene and shut down that kind of stuff. There's a problem that I've been working on in this area. And I could use help in not being the only one telling this person to go away. I think he did the save one, I guess. I mean, I'm gonna save John the nervousest. His initials are BS and that's a lot of what he produces. Actually, you mentioned Randy, Randy Dunlap. I wonder if we can persuade him to, by persuade, I mean pay or contract to him to actually produce some documentation because he writes marvelously well. So Randy does very good proofreading, but he's not a memory management specialist, by any means. No, but he's got technical chops. He understands when he's reading code what it means. I don't, I would rather take the doc's written by him than by almost anybody else. One of the best reviewers I've ever known was Michael Karisk, man pages maintainer. Often I get a new sys call and everybody thought, look great, yet ship it and then Matthew comes in and takes a look and tore it apart. Michael's been quiet in recent times, unfortunately. So as usual, we reached the conclusion we need more documentation and we don't really know what to do about it. Yes, Dan? What do you think are the highest priority areas or is all the above? I would say that the table of contents Matthew laid out is pretty much the most important technical documentation that we have right now. So, process memory management, page tables, what, what, Vmalloc as well, Blood Do Hear Us, and Reclaim, S-Lamb. They saw quite important to document so people would know how to work with them. People would understand what is going on there at least to some extent. So whatever we can do will be better. Priority-wise, I don't know, I usually try to write about things I do understand. So that's why I kind of wrote the half page about nodes and initialization and I stopped at zones because I have no clue what's going on there. But then there is Liam to write about process and after all VMA work they've done and there should be page cache documentation somewhere, I suppose. I mean, there's a lot of kernel dock in the, but there's not the overriding, this is what a page cache is document and that wouldn't really take me long to hammer out. It's just that I also have other code that I need to write as well as other documentation. Yeah, of course. So, you know, do you want me working on folios or do you want me writing documentation? I mean, well, that's the usual trade-off, right? And what do we do now, Andrew? So that's all I have. I think we can stop here.