Received: by 10.192.165.156 with SMTP id m28csp1105557imm; Fri, 13 Apr 2018 13:22:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jekMnxNzHQch1RvWOSrzjxmFf7nkPQiS8fosDNnljIXa5horFUefDEv1cjb1JvRdVFn7z X-Received: by 10.99.119.133 with SMTP id s127mr5112646pgc.441.1523650971106; Fri, 13 Apr 2018 13:22:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523650971; cv=none; d=google.com; s=arc-20160816; b=EuLzxWhPWMbwZheBN+fBketgxRv7dXl5sxCNzWQg4X5Bqdsm1XsMYGj+1yEaC4CSt6 1CVFokODWGT+ta475CIlFdnXYJ7Zku/gJvLr/59jWbs2fH91O/fqE/Kzfvwt1x6vf5oR Tw2BWT2XyfPPRRjsmr7uMgSfG0qs+L9MlsUHcpEvh5fMIS6L+Mu2bhyF7P+dMd1E6KAv TBzfB/OiQ72ccb7nccKLKr9m7efcjR1RkeE3iiGDESe9c87DNc6h4U0kC/sMnSlI3AIn 4Y99dX69Ml+GPm5Wnev0+UaoHayAe+ZDxwu/eu+YJWU754MgvBRULlr8TzPnl+ymn2ce uQBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=rF70eO+AC+qHNSHLVvrUh1edH14m7X/avjRx8+wqxVg=; b=JDUqdEz9cVXdPhZ19ukKy+xgyMAHxDiVIAdalIKItbs3kiW+AvgjLFwzu4LwG25N6j zbfoYxi31KRh2LcC48a6mKWkqT4bzDzehdXGM9Q+c+VVKTyo/Uv+I+st/SHPI1lLZc5G s+BBwGYe3iWys/YjZN8y0L0Ct3bb5ebnjLMuh/WoRbJBoTfLNOtWkNRs5S+zJAmv/3HK VvtWa+aL4EZvezJrImtALfTBvnpczxq4rec8dAUgdIOvSe7k4NpZRaX2HitbLBDq2nmS MRz+vD94yDRuhih1FzEOCCqXB+PxdVJ6J6+fpb3HcjzNaJ55yTtXhJ0HAnvPHPiMbNSR b0Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=tHDwkyA8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bg3-v6si5929028plb.118.2018.04.13.13.22.36; Fri, 13 Apr 2018 13:22:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=tHDwkyA8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751632AbeDMUVa (ORCPT + 99 others); Fri, 13 Apr 2018 16:21:30 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:55250 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036AbeDMUV1 (ORCPT ); Fri, 13 Apr 2018 16:21:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rF70eO+AC+qHNSHLVvrUh1edH14m7X/avjRx8+wqxVg=; b=tHDwkyA8MaLiZFlQ7qKS1qQyW cWxCnONtbGtpKy/ccaz/IuVvgHhk2NUQOpn3bJCt/Bq6hK6qroLxLHkxByhZoXD5RuDy/krWsyb42 j/C8cD2sp6Xk6QEn6pxTJDLYmL3qJSIW6J8Ij4HfA0fIh4gFFwhR0kHvBF0888VqQ6vLCxCu2s1mv UPMw+lflINX6dYMzTQoJ2tXWbLYlQpiAHoqIqLw/eKnKc/qtyTrLKlNH1wlNUOed13NVhL5uW5ibl SM4xFTlLNTuXkh9b0RWSL30+5K2ClMrv1NnS1bSPGfWrjjvyZGhrL6DF4J2KO8PG1Rtgjzmo0X3Gk mUZbU91bw==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1f75C0-0002yn-EK; Fri, 13 Apr 2018 20:21:08 +0000 Date: Fri, 13 Apr 2018 13:21:08 -0700 From: Matthew Wilcox To: Jonathan Corbet Cc: Mike Rapoport , Andrew Morton , Andrey Ryabinin , Richard Henderson , Ivan Kokshaysky , Matt Turner , Tony Luck , Fenghua Yu , Ralf Baechle , James Hogan , Michael Ellerman , Alexander Viro , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kasan-dev@googlegroups.com, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 00/32] docs/vm: convert to ReST format Message-ID: <20180413202108.GA30271@bombadil.infradead.org> References: <1521660168-14372-1-git-send-email-rppt@linux.vnet.ibm.com> <20180329154607.3d8bda75@lwn.net> <20180401063857.GA3357@rapoport-lnx> <20180413135551.0e6d1b12@lwn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180413135551.0e6d1b12@lwn.net> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote: > > I believe that keeping the mm docs together will give better visibility of > > what (little) mm documentation we have and will make the updates easier. > > The documents that fit well into a certain topic could be linked there. For > > instance: > > ...but this sounds like just the opposite...? > > I've had this conversation with folks in a number of subsystems. > Everybody wants to keep their documentation together in one place - it's > easier for the developers after all. But for the readers I think it's > objectively worse. It perpetuates the mess that Documentation/ is, and > forces readers to go digging through all kinds of inappropriate material > in the hope of finding something that tells them what they need to know. > > So I would *really* like to split the documentation by audience, as has > been done for a number of other kernel subsystems (and eventually all, I > hope). > > I can go ahead and apply the RST conversion, that seems like a step in > the right direction regardless. But I sure hope we don't really have to > keep it as an unorganized jumble of stuff... I've started on Documentation/core-api/memory.rst which covers just memory allocation. So far it has the Overview and GFP flags sections written and an outline for 'The slab allocator', 'The page allocator', 'The vmalloc allocator' and 'The page_frag allocator'. And typing this up, I realise we need a 'The percpu allocator'. I'm thinking that this is *not* the right document for the DMA memory allocators (although it should link to that documentation). I suspect the existing Documentation/vm/ should probably stay as an unorganised jumble of stuff. Developers mostly talking to other MM developers. Stuff that people outside the MM fraternity should know about needs to be centrally documented. By all means convert it to ReST ... I don't much care, and it may make it easier to steal bits or link to it from the organised documentation.