From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 21:50:29 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 3884F16A41C; Wed, 6 Jul 2005 21:50:29 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9333B43D46; Wed, 6 Jul 2005 21:50:28 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 4B5DABC51; Wed, 6 Jul 2005 21:50:26 +0000 (UTC) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 06 Jul 2005 14:20:43 PDT." <20050706212043.GA6215@ns1.xcllnt.net> Date: Wed, 06 Jul 2005 23:50:25 +0200 Message-ID: <9120.1120686625@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Poul-Henning Kamp , Maxim.Sobolev@portaone.com, Giorgos Keramidas , freebsd-current@freebsd.org 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 21:50:29 -0000 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. 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. You have to put that MBR magicness, BSD magicness and GPT, Apple, Sun magicness *somewhere* in the end, and what's more, you have to be able to give the user a sensibly detailed explanation of what happened and why. If we are willing to forgo that kind of DWIM, then I don't see a problem, but quite frankly: I hate having to add obscenely large sectornumbers in my head myself, so I suspect we want at least some level of DWIM. And while diskpartitioning sounds like a great OO programmin excercise or as somebody who shall remain uname suggested: "use PROLOG to resolve the constraints in optimal fashion", one should not forget that this is a seldomly used system administration tool. It is simply not worth spending a year of your life on (IMO). So I tend to lean towards a model where we fix the major loosage in the existing tools (mostly fdisk really) and leave it at that. With respect to the current tools, fdisk just sucks. The userinterface of bsdlabel is much better (the save/restore thing and the use of the users own editor is great). Sysinstall is not my cup of tea, but does give some of the visual feedback DWIM that people want. With all that discouragement out of the way, if somebody wants to do more about it, they are more than welcome. Burned by my own experience, I would advocate a lot of prototyping because there doesn't seem to be a free lunch anywhere in this area. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.