From owner-freebsd-geom@FreeBSD.ORG Fri Nov 1 10:32:04 2013 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B53849C for ; Fri, 1 Nov 2013 10:32:04 +0000 (UTC) (envelope-from symbolics@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B00F82FD4 for ; Fri, 1 Nov 2013 10:32:03 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M1BMy-1Vvvrd3e5A-00tFPG 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:ChKUbVSK2ZyzD55yIzhYQQ2biJfWTOC4/9FPwheFaRSiwnhkrc+ KPoqst+s3VRRS1KkiASnnWhm/ScFdupMyZiVzlmBlXzsSdiy/PhtAiBnve0Z+0aaY8/HF25 QEu3KrYRgBNp/HFu+0dJauw4gZ9fuf0x0dvFS7xSNNQK5fuYw77J+6w5Z31FbUr0iaQIRRp 2z/tT9vhf3UvniT4Nt0Uw== Cc: geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:32:04 -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