From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Mar 2017 23:45:52 +0100 (CET) Received: from mail-wr0-x242.google.com ([IPv6:2a00:1450:400c:c0c::242]:34707 "EHLO mail-wr0-x242.google.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23994231AbdCMWpp4lB-A (ORCPT ); Mon, 13 Mar 2017 23:45:45 +0100 Received: by mail-wr0-x242.google.com with SMTP id u48so21899557wrc.1; Mon, 13 Mar 2017 15:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:date:to:cc:subject:message-id:mail-followup-to:mime-version :content-disposition:in-reply-to:user-agent; bh=obqr0DX1/kdLIbymNY1r8hEPwuhD6CNhDknDx2xbFbA=; b=fuy5BgdoB+/FuVYdufqmKyuyKGfwGt7XoNg4q02V9RMGKVJC40ke0vVjbGkLfdr0AD aQWsqFKuGZ+l24NxOa1U6vsIDkXIEJ2hbIdVWFOvFJYF5TmW960pw7sD/cIuUX8npeX4 oEEFhjhlf62XHcyA6iQXyUy0p0BEZUcJZqnX6YCLkVf3ka2wOeltt4lXCS303HHdUu7f 1WxnSkJGqESSQAGXb1wKi/wJr7ClJlelA15ftj4gWwYrD+t5v4HS/ReZfuZe7PUn84n5 Tmqfw9x+QdthZ440v4SZ3krSoBC0DYI9WI0I1DFsRDFGMD7enniLFgBVz198rlKb5fJU oizw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition:in-reply-to :user-agent; bh=obqr0DX1/kdLIbymNY1r8hEPwuhD6CNhDknDx2xbFbA=; b=IvAIqfwgH/5mLwK6eUHq7Ky8Q7Hos9DYtPs7zbakno5mfcPgeWSKR+9L406KJcFYur NJKJgGqRSByRPId/7OH1HyYYOTEiPwHD8LfPeouf+snT57/TXTL0vQnjpxGq28vc0grf AivOWJV7eGeQM5kNthxQhAza+isNx47/lfgZ5+uhyM/7NcJsfeh5snwkrP57oOuikA8M UrQUzTGPRsiYs+ZWoc4P/COTm1/+syX7F44U9D+Yqesx5OuOT1ajmRaUWujYrBQ+zM9f NopcreH4o9I944RbNfzBAQDPFe6TziAqD3cF7KX/5nPamOHPsRpZq9sd1lhhMLoYf3MZ uxUw== X-Gm-Message-State: AMke39mge/KO6DpzTgB8oO+hO3RLe0q+S248y48zg9LQVwfdXCvBsPlnLiftU9UlXJgxxg== X-Received: by 10.223.163.21 with SMTP id c21mr29143221wrb.115.1489445140611; Mon, 13 Mar 2017 15:45:40 -0700 (PDT) Received: from localhost (login1.zih.tu-dresden.de. [141.76.16.140]) by smtp.googlemail.com with ESMTPSA id 136sm13009812wmg.12.2017.03.13.15.45.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Mar 2017 15:45:39 -0700 (PDT) From: Till Smejkal X-Google-Original-From: Till Smejkal Date: Mon, 13 Mar 2017 15:45:36 -0700 To: Matthew Wilcox Cc: Till Smejkal , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Miao , Richard Kuo , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Andy Lutomirski , Chris Zankel , Max Filippov , Arnd Bergmann , Greg Kroah-Hartman , Laurent Pinchart , Mauro Carvalho Chehab , Pawel Osciak , Marek Szyprowski , Kyungmin Park , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Felipe Balbi , Alexander Viro , Benjamin LaHaise , Nadia Yvette Chambers , Jeff Layton , "J. Bruce Fields" , Peter Zijlstra , Hugh Dickins , Arnaldo Carvalho de Melo , Alexander Shishkin , Jaroslav Kysela , Takashi Iwai , linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-media@vger.kernel.org, linux-mtd@lists.infradead.org, linux-usb@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-mm@kvack.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions Message-ID: <20170313224536.saqdijtdayxwmlpz@arch-dev> Mail-Followup-To: Matthew Wilcox , Till Smejkal , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Miao , Richard Kuo , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Andy Lutomirski , Chris Zankel , Max Filippov , Arnd Bergmann , Greg Kroah-Hartman , Laurent Pinchart , Mauro Carvalho Chehab , Pawel Osciak , Marek Szyprowski , Kyungmin Park , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Felipe Balbi , Alexander Viro , Benjamin LaHaise , Nadia Yvette Chambers , Jeff Layton , "J. Bruce Fields" , Peter Zijlstra , Hugh Dickins , Arnaldo Carvalho de Melo , Alexander Shishkin , Jaroslav Kysela , Takashi Iwai , linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-media@vger.kernel.org, linux-mtd@lists.infradead.org, linux-usb@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-mm@kvack.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, alsa-devel@alsa-project.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170313222758.GB4033@bombadil.infradead.org> User-Agent: NeoMutt/20170306 (1.8.0) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 57183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: till.smejkal@googlemail.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips Hi Matthew, On Mon, 13 Mar 2017, Matthew Wilcox wrote: > On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote: > > +/** > > + * Create a new VAS segment. > > + * > > + * @param[in] name: The name of the new VAS segment. > > + * @param[in] start: The address where the VAS segment begins. > > + * @param[in] end: The address where the VAS segment ends. > > + * @param[in] mode: The access rights for the VAS segment. > > + * > > + * @returns: The VAS segment ID on success, -ERRNO otherwise. > > + **/ > > Please follow the kernel-doc conventions, as described in > Documentation/doc-guide/kernel-doc.rst. Also, function documentation > goes with the implementation, not the declaration. Thank you for this pointer. I wasn't aware of this convention. I will change the patches accordingly. > > +/** > > + * Get ID of the VAS segment belonging to a given name. > > + * > > + * @param[in] name: The name of the VAS segment for which the ID > > + * should be returned. > > + * > > + * @returns: The VAS segment ID on success, -ERRNO > > + * otherwise. > > + **/ > > +extern int vas_seg_find(const char *name); > > So ... segments have names, and IDs ... and access permissions ... > Why isn't this a special purpose filesystem? We also thought about this. However, we decided against implementing them as a special purpose filesystem, mainly because we could not think of a good way to represent a VAS/VAS segment in this file system (should they be represented rather as file or directory) and we weren't sure what a hierarchy in the filesystem would mean for the underlying address spaces. Hence we decided against it and rather used a combination of IDR and sysfs. However, I don't have any strong feelings and would also reimplement them as a special purpose filesystem if people rather like them to be one. Till