From owner-freebsd-geom@FreeBSD.ORG Wed Nov 24 08:30:43 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DAFA16A4CE for ; Wed, 24 Nov 2004 08:30:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C84F43D54 for ; Wed, 24 Nov 2004 08:30:42 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAO8UfRC061191; Wed, 24 Nov 2004 09:30:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jeremy Faulkner From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 23 Nov 2004 10:12:36 EST." <41A35364.6030908@gldis.ca> Date: Wed, 24 Nov 2004 09:30:41 +0100 Message-ID: <61190.1101285041@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: geom@freebsd.org Subject: Re: report on GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 08:30:43 -0000 In message <41A35364.6030908@gldis.ca>, Jeremy Faulkner writes: >http://www.gldis.ca/gldisater/TechnicalReport-GEOM.pdf first page: s/that the read has/that the reader has/ In general I would refrase everything from "It is also assumed..." to not involve the reader at all, but merely state that we use the following convention: ... second page: 1 "DEVFS " - Rather than the footnote approach I would probably just mark the glossary entries in some (subtle!) way. s/connected to a FreeBSD computer system// You already said that this was FreeBSD. It doesn't run without the computer. "will be different..." You probably need to give an example. "an event queue" Actually there is an event queue for changes to the topology and two I/O queues for pushing data up respectively down. You should explain that the provider is the service point and that a consumer is used to access that service. You will probably want to note that multiple consumers can attach to one provider, but not the other way around. The provider doesn't "give[s] the associated consumers ...". The consumers are not associated but attached, and they request the information out of the provider, it's not the provider pushing the information on the consumers. Also, you list only the mandatory attributes, there are optional attributes handled with the BIO_GETATTR request. Loose all exclamation marks. "The two geoms..." I would loose the rather rambling text from here and instead explain what happens when the system boots: First the diskdriver finds a drive and greates an geom_disk instance "ad0" and gives it a provider. The "tasting" happens and the MBR class finds MBR paritition metadata and decides to ... etc. You probably want to give the stripe-before-mirror vs. mirror-before-stripe example (graphically ?) to show why free stackability is important. -- 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.