From owner-freebsd-arch Sun May 7 20:29:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 98F0037BCB5; Sun, 7 May 2000 20:29:23 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id VAA04115; Sun, 7 May 2000 21:23:52 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200005080323.VAA04115@caspian.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: Poul-Henning Kamp , "Justin T. Gibbs" , FreeBSD-arch@FreeBSD.ORG Subject: Re: Support for bootable Vinum file systems: please review In-Reply-To: Your message of "Sun, 07 May 2000 17:46:39 +0930." <20000507174638.E55316@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 May 2000 21:23:51 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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. 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. >Anyway, I assume this isn't so much a criticism of the fix as of the >infrastructure around it. Correct? It depends on whether you want an expedient "hack" or a generic, long lived, solution. >> 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. One other comment about the patches... they violate existing style (and style(9)) in vfs_conf.c. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message