From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 23:59:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65AB416A41C; Wed, 6 Jul 2005 23:59:57 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27A1943D46; Wed, 6 Jul 2005 23:59:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j66Nxrr6006994; Wed, 6 Jul 2005 16:59:55 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <9120.1120686625@phk.freebsd.dk> References: <9120.1120686625@phk.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 6 Jul 2005 16:59:52 -0700 To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.622) Cc: freebsd-current@freebsd.org, Giorgos Keramidas , Maxim.Sobolev@portaone.com Subject: Re: [TEST/REVIEW] boot0cfg/fdisk issue fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2005 23:59:57 -0000 On Jul 6, 2005, at 2:50 PM, Poul-Henning Kamp wrote: > In message <20050706212043.GA6215@ns1.xcllnt.net>, Marcel Moolenaar > writes: > >> That would be better, yes. Would a slicer-specific API that's >> implemented in terms of g_ctl be welcome in libgeom? It would >> help convert the existing tools to use GEOM more directly, >> which helps the convergence of the functionality into a single >> tool: geom(8). For geom(8) it would then probably be a class >> library, right? > > My worry about this is that the "DWIM" aspect will render most > generic stuff obsolete. Doesn't that depend entirely on having the necessary abstractions and having those translated to hard "currency" at the right time? Where "the right time" is not too soon (i.e. at a level too high, say the UI) or too late (i.e. at a level to low, say the hardware driver). > For instance, in a MBR, if I say > "create ad0s3 max" > in order to use the largest free slap of space, that end sector > number should be rounded down to a cylinder boundary and the start > sector number to a track boundary if it would otherwise occupy the > first track. But this example merely demonstrates that sizes and offsets are subject to normalization at the slicer level and that any attempt to conclude anything at the levels above it prior to the normalization is moot. It doesn't show that "create ad0s3 max" can not be implemented using a generic API. If you add a normalization function to the API that lets slicers round up or round down based on geometry constraints, then at the higher levels you don't have to worry about it (other than making sure that you work with normalized values). We already have the magic in libdisk. We only need to beef up the interface so that it isn't only usable by sysinstall. This might be a good way to prototype and work towards a common API and a common tool. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net