From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 01:25:23 2009 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44A0A1065670 for ; Sat, 21 Mar 2009 01:25:23 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id D1CBA8FC08 for ; Sat, 21 Mar 2009 01:25:22 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by bwz8 with SMTP id 8so1030700bwz.43 for ; Fri, 20 Mar 2009 18:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.55.142 with SMTP id u14mr1450205bkg.121.1237597059297; Fri, 20 Mar 2009 17:57:39 -0700 (PDT) In-Reply-To: References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> Date: Sat, 21 Mar 2009 01:57:39 +0100 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 01:25:23 -0000 On Sat, Mar 21, 2009 at 00:34, Ivan Voras wrote: > Luigi Rizzo wrote: >> On Thu, Mar 19, 2009 at 12:41:13PM +0100, Marius N?nnerich wrote: >>> 2009/3/19 Luigi Rizzo : >>>> Hi, >>>> >>>> Fabio Checconi and I have been thinking on how to implement "proxy" >>>> geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer >>>> port, do not do any data transformation, and can be transparently >>>> inserted or removed on top of a provider port while the tree is >>>> actively moving data. >> ... >>>> The idea is to intercept requests coming on a provider port, pp, and >>>> redirect them to a geom node acting as a proxy if the port >>>> is configured in this way: >> ... >>> I wonder if it's really necessary to alter the GEOM infrastructure or >>> if it is possible to do this with what's there already. Just an idea: >>> Lock g_topology, put g_down and g_up to sleep, alter the consumer and >>> provider pointers where you need it so the everything is routed >>> through your proxy class (which isn't special in any way) and restart >>> g_down and g_up. >> >> we'll look into this, thanks. If we can spare the extra fields >> in the g_provider, the thing is even easier to do. >> >> I just don't know how your suggestion interferes with the naming: >> if I change the pointers, the name of a provider will not >> be anymore a prefix of the name of the node attached above. >> But maybe that is not an architectural requirements but just >> a convenient convention. > > Not only with naming and device creation - the proxy classes cannot be > "normal" classes because it's common that "normal" classes do a lot of > initialization in .taste. (i.e. there at least needs to be a flag for > proxy classes) Take a look at geom_nop, it doesn't taste. It is like a proxy already as far as I can see. I don't know what to do about the naming though.