From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 10:32:11 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 753C04CB for ; Fri, 1 Nov 2013 10:32:11 +0000 (UTC) (envelope-from symbolics@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE2C62FD6 for ; Fri, 1 Nov 2013 10:32:10 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUDXS-1VBLUp3nZy-00R13Y for ; Fri, 01 Nov 2013 11:32:02 +0100 Received: by lemon (Postfix, from userid 1001) id 4647FEB372; Fri, 1 Nov 2013 10:31:58 +0000 (GMT) Date: Fri, 1 Nov 2013 10:31:58 +0000 From: symbolics@gmx.com To: hackers@freebsd.org Subject: GEOM mentor request Message-ID: <20131101103158.GA35397@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Provags-ID: V03:K0:973fMirGNLIq8cR8nfTacXwjIWVhbG6jOcN0xJ6fpolhg+/PGnD a+zEEs0f/GLt4uGuAGkv8WNVPiM0W8MLqWNJasx5mKMabdw9QUPXl81DNw3qbQM6ycHmHfM CLddAQXQd56zLBS5c9EBhIYfxsXVxc2LKvplh0m57qMqEhRPVda43j5CJvW8xk80LaeNVAY YygrFIcFV4xFNYO7QLGQw== Cc: geom@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:32:11 -0000 Hi hackers, I have been studying the GEOM documentation and source recently. Is anyone actively maintaining this subsystem at the moment? I would like to give it some attention. A few example things I'd like to work on (in no particular order): + Developer manual pages. Rewrite for clarity and add cover some of the areas not discussed yet. + Add a tutorial on writing GEOM classes, either in the dev handbook or within the manual pages. + Add missing manual pages so every class has a complete set. + Implement various helper methods to reduce code duplication across GEOM classes. There seems to be quite a bit of C&P currently. + Attack GEOM PR list. Lots of PRs have not progressed in a long time. + Implement a method for controlling tasting; there are some cases where this would be helpful. Bhyve is one, apparently iSCSI might be another. + I have a patch that adds connect/disconnect verbs to the DISK class. Disconnect sets a flag that disables tasting on the geom and withers all but the GEOM's DEV provider. This lets me use a raw disc with virtio-blk in Bhyve (with a few other problems). + Add regression tests for various classes, especially the ones that do not support writing metadata and are therefore more difficult to test, LINUX_LVM, for instance. + Try and resolve the various XXX comments sitting in the code. + Implement new things. Some ideas I have had: + GEOM "ERASE" - Rewrite deletes into random writes. + GEOM "PLUG" - Persistent version of the connect/disconnect verbs where the flag sits in the class metadata. This might be a cleaner approach, rather than adding the verbs to all the existing providers. + GEOM "TAP" - Allow userspace processes to hook into the GEOM API. Intended for debugging and development. + GEOM "WCACHE" - Allow you to use small, fast provider as a buffer for a larger, slower provider. + GEOM DTrace provider. Provide GEOM specific probes to complement the IO provider. + Probably other bits I can't remember right now. I need someone more experienced in kernel programming who can review my ideas and work and guide my patches into the tree. Given that lots of the GEOM PRs don't seem to be moving, I don't really want to do the work for it to rot in GNATS. Any volunteers please get in touch. Thanks! --sym