From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:43:44 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 CEF6B16A41C; Wed, 6 Jul 2005 19:43:44 +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 328CC43D49; Wed, 6 Jul 2005 19:43:44 +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 A3FF7BC51; Wed, 6 Jul 2005 19:43:41 +0000 (UTC) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 06 Jul 2005 11:13:10 PDT." <20050706181310.GA5167@ns1.xcllnt.net> Date: Wed, 06 Jul 2005 21:43:40 +0200 Message-ID: <8285.1120679020@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 19:43:44 -0000 In message <20050706181310.GA5167@ns1.xcllnt.net>, Marcel Moolenaar writes: >On Wed, Jul 06, 2005 at 07:58:23PM +0300, Maxim Sobolev wrote: >A completely different approach that helps to abstract the details >of the slicer (i.e. MBR, GPT or BSD) is a functional interface. >Have a device special file for each slicer and implement ioctl(2) on >them for adding, removing, resizing etc of partitions. That way >GEOM gets to see requests like: > "remove slice number 3, please" If you want to implement this, don't add bogodevices with magic ioctls, use the g_ctl API instead, it is designed for this kind of thing. The main reason I have not implemented something like what you suggest is that I don't think it makes life that much easier for us to put it in the kernel. First of all, it is code which is extremely seldomly used, and it is not a trivial amount of code to add, so the cost/benefit is dubious at best. Second, there is no real advantage to doing it in the kernel that cannot be realized equally or better entirely in userland. >Potentionally we could end up with a single tool to manipulate any >and all slicers, provided we define the ioctl interface correctly. My original hope was that this tool would be called geom(8) and be the unified management tool for all GEOM classes, not just slices. I can't see why it would have to matter to the user what kind of GEOM class implements a given function, slicing, mirroring or RAID3, the commands to fiddle it should be the same. -- 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.