From owner-freebsd-arch Mon May 8 1:20: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 4AF3A37B5F0; Mon, 8 May 2000 01:19:25 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id RAA68444; Mon, 8 May 2000 17:49:13 +0930 (CST) Date: Mon, 8 May 2000 17:49:12 +0930 From: Greg Lehey To: "Justin T. Gibbs" Cc: Poul-Henning Kamp , FreeBSD-arch@FreeBSD.ORG Subject: Re: Support for bootable Vinum file systems: please review Message-ID: <20000508174911.W61921@freebie.lemis.com> References: <20000507174638.E55316@freebie.lemis.com> <200005080323.VAA04115@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200005080323.VAA04115@caspian.plutotech.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 7 May 2000 at 21:23:51 -0600, Justin T. Gibbs wrote: >>> The right way to do it is probably to link the "struct disk"s >>> registered by the drivers with disk_creat() into a list which can >>> be searched. >> >> This is pretty much what struct devstat does, except that it's more >> global. Why should we maintain two lists, just because one is >> primarily intended for statistics? > > Because it was only intended for statistics. It by chance it proves to be ideally suited for something else, should we limit ourselves to the imagination of the designer? > My belief, and this is probably shared by phk, is that the handlers > for different partition types should be "executed" or "attached to" > as those partitions are found. A scan of a list is only necessary > in the event of a handler being registered after a partition is > found. Although devstat may suffice for the latter, it was not > designed to handle the former. 'GEOM' is what you want although I > don't know how soon phk can provide it to you. As I've said, I'm quite prepared to do that. >>> Another thing that is ugly about this is the kludge in the partition >>> table. I'd rather see us finally bite the bullet and move to an >>> extensible disklabel scheme. >> >> Again, may I take this as a criticism of the infrastructure rather >> than the fix? > > I'd rather see Vinum be the champion of improved infrastructure than > another reason to sustain the status quo. I didn't go into details about this one because I'm still thinking about it. I'm certainly thinking about viable alternatives, but it depends on how central Vinum should be. > One other comment about the patches... they violate existing style > (and style(9)) in vfs_conf.c. Can you be more specific? Offline would be fine. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message