From owner-freebsd-geom@FreeBSD.ORG Mon Apr 23 20:24:08 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22D4416A404 for ; Mon, 23 Apr 2007 20:24:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CDF6A13C489 for ; Mon, 23 Apr 2007 20:24:07 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D7CB0173B4; Mon, 23 Apr 2007 20:24:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l3NKO4no004521; Mon, 23 Apr 2007 20:24:04 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 23 Apr 2007 12:52:18 MST." Date: Mon, 23 Apr 2007 20:24:04 +0000 Message-ID: <4520.1177359844@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT as default? 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: Mon, 23 Apr 2007 20:24:08 -0000 >As time passed people started to complain more about the lack of using >verbs to do the partitioning. That's just the nature of things and I'm >working on it. Before you guys rip each other another one, I just want to chime in with some background: For the existing classes, MBR, BSD and PC98 it was necessary to emulate enough of the old ABI that it was simpler to implement the "here is your completely new metadata as a binary blob" style change ioctls. Doing it this style has some advantages, most notably that you can reuse the 'taste' function to validate the proposed metadata, if you arrange it the right way. That means the minimum amount of code in the kernel and the majority of it in a seldom invoked executable. One disadvantage is that it is very messy for a class like MBREXT here metatada is all over the media. (That's why we have never really supported editing extended partitions, nobody wanted to deal with that mess.) Compared to this is the verb-based style, which puts (much) more of the complexity in the kernel with the potential benefit that one could conceiveably use a unified userland tool for vastly different classes, because now the kernel code knows all the magic details. Finally, one should realize, that we are talking about an API/ABI that seldom, if ever, gets invoked more than once for a given system, and that is during installation where the system already run a highly magic application, for that very reason. I find it counterintuitive to put the complexity into the kernel for a so seldomly used API/ABI, so I _personally_ prefer the "here is your metadata as a binary blob" style. However, As architect of GEOM I have sworn not to dictate people how they write their classes or what their classes do or should do, apart from the fundamental GEOM architecture and interfaces, which are pretty well protected by my liberal application of KASSERT. But it would clearly be an advantage if all the slicers used or at least supported the same style... 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.