From owner-freebsd-geom@FreeBSD.ORG Fri Mar 21 17:16:15 2008 Return-Path: Delivered-To: geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC650106564A for ; Fri, 21 Mar 2008 17:16:15 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.78]) by mx1.freebsd.org (Postfix) with ESMTP id A6A928FC1C for ; Fri, 21 Mar 2008 17:16:15 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id m2LHGFJa025931 for ; Fri, 21 Mar 2008 10:16:15 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m2LHGD3t000976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Mar 2008 10:16:13 -0700 (PDT) Message-Id: <500B8D5E-A46F-48AF-A835-97C46ED36F91@mac.com> From: Marcel Moolenaar To: geom@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 21 Mar 2008 10:16:12 -0700 X-Mailer: Apple Mail (2.919.2) Cc: Subject: Q: force/trigger a retaste 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: Fri, 21 Mar 2008 17:16:15 -0000 All, I'm working on module support for GPART and I have a need trigger a retaste. When we load a GEOM module (read: load a class), the GEOM infrastructure will present all existing providers to the new class's taste buds. This will do the right thing out of the box. With GPART, we can dynamically load and unload partitioning schemes. A partitioning scheme is not a GEOM class, so the loading of a new scheme does not cause a new class to be loaded and as such will not cause any re-tasting. As such, when I have a disk with, say, a GPT but don't yet have support for the GPT scheme, then loading the GPT scheme will not automatically result in the creation of new providers. What needs to happen is that an existing class (i.e. the GPART class) gets to taste all existing providers again, so that it can attach to providers it previously did not attach to (due to a change in the supported schemes). I can definitely put the necessary code in GPART itself, but that may lead to duplication. But maybe it's more beneficial to make it generic. I'm thinking about something like: void geom_retaste(struct g_class *mp) { struct g_class *clp; struct g_geom *gp; struct g_provider *pp; g_topology_assert(); LIST_FOREACH(clp, &g_classes, class) { LIST_FOREACH(gp, &clp->geom, geom) { LIST_FOREACH(pp, &gp->provider, provider) { if (pp->acr + pp->acw + pp->ace == 0) { mp->taste(mp, pp, 0); g_topology_assert(); } } } } } Is this correct? Shall I make this a generic GEOM function or keep it private to GPART? Thanks, -- Marcel Moolenaar xcllnt@mac.com