From mboxrd@z Thu Jan 1 00:00:00 1970 From: Latchesar Ionkov Subject: RFC: 9p filesystem interface Date: Thu, 9 Mar 2006 17:57:38 -0500 Message-ID: <20060309225738.GA17780@ionkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: v9fs-developer@lists.sourceforge.net Return-path: Received: from rwcrmhc14.comcast.net ([216.148.227.154]:7101 "EHLO rwcrmhc14.comcast.net") by vger.kernel.org with ESMTP id S1750784AbWCIWz5 (ORCPT ); Thu, 9 Mar 2006 17:55:57 -0500 To: kernel-mentors@selenic.com, linux-fsdevel@vger.vger.kernel.org Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, Translating Plan9's 9P protocol to the Unix world is not very straightforward task. We already have the basic functionality implemented, but there are still some missing pieces: User authentication 9P protocol requires every user the authenticate separately to the server. There is not defined authentication protocol, 9P assumes that the client knows what authentication is required by the server. The authentication is performed by creating an authentication channel to the server and reading/writing on it. When the auth conversation is done, the client "attaches" to the server passing the authentication channel id. We don't want to hardcode any specific auth protocol in the kernel, we would rather have a way to expose the per-user per-mount authentication channel to the user space and let a program take care of the authentication. We are discussing whether to do on-demand, user-initiated authentication, or both. Currently v9fs attaches as a single user and the file operations for all users are done with that user name. Error mapping In the 9P protocol all errors are reported as textual strings. VFS expects errors to be numeric values. Different file servers return different error names, there is no common set of error names. We need a way to configure v9fs of the mapping for particular file server. Currently v9fs has a static mapping of the error names found in the most used file servers. User mapping Users and groups in 9P are also identified by textual strings. VFS expects numeric uids. We need a way to configure a mapping between the user names and user ids. Currently we don't do any mapping. We need a per-v9fs-mount interface that we can use for authentication, error and user mapping. We are evaluating three options -- adding v9fs tree in procfs, adding v9fs tree in sysfs, and defining a special directory on the root level of the tree served by v9fs. Procfs If we implement procfs interface, we would add a new directory -- fs/v9fs. The top level will contain the global configuration options for the fs. There will be subdirectories that will contain the files used to configure the specific mounts. When an unauthenticated user tries to perform a file operation on an v9fs file, v9fs will create a file in fs/v9fs/nnn directory that can be used for authenticating that user. Pros: It is going to use existing kernel framework. Cons: Having chroot, mount --bind, multiple mounts on the same mount-point etc., it is going to be hard to find out which fs/v9fs/nnn subdirectory belongs to which tree. Sysfs Sysfs is similar to procfs, but it has one more disadvantage: there is a limit of the size of the files. There is no guarantee how much data will be tranferred during the authentication conversation. We can work around that restriction by doing lseek(fd, 0, SEEK_SET) before we read from the authentication file exposed in sysfs, but it is ugly and against common sense. Special directory The third option is to expose the files as a special directory in the roots of the trees served by v9fs. The directory (.9p or #9p) is going to behave differently than the rest of the files v9fs serves. The files in the directory will be handled by v9fs locally and will be used for authentication, error and user mapping. Pros: It is easier to find the files for a specific mount. Cons: Having special files that behave differently may lead to some confusion. We would like to get your opinions on what is the preferred linux-kernel way of implementing the 9p-to-user-space interface. Thanks, Lucho