From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 00:19:57 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45421065673 for ; Wed, 18 Feb 2009 00:19:57 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id BFD248FC1D for ; Wed, 18 Feb 2009 00:19:57 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [172.24.240.93] (natint3.juniper.net [66.129.224.36]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF800E68JL7QB60@asmtp019.mac.com> for current@FreeBSD.org; Tue, 17 Feb 2009 16:19:57 -0800 (PST) Message-id: From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <16678.1234910124@critter.freebsd.dk> Date: Tue, 17 Feb 2009 16:19:55 -0800 References: <16678.1234910124@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? 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, 18 Feb 2009 00:19:58 -0000 On Feb 17, 2009, at 2:35 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >>> In message , Marcel >>> Moolenaar wri >>> tes: >>> >>>> For boot0cfg this is probably acceptable, because >>>> it only operates on MBRs. But as a generic solution >>>> this won't work. >>> >>> Then pick up the bootcode via ioctls, it does not belong >>> in the confxml sysctl. >> >> On what grounds doesn't it belong in the confxml? > > Because the way we (currently) implement confxml and the uses it is > put to would generally be greatly inconvenienced if you have to > include > 8KB of hexdump data in the xml stream. > >> And how do these not apply to ioctls? > > ioctls was designed and built to move binary blobs across the > userland/kernel barrier to and from I/O devices. I'll consider this. From my perspective: o The fact that we have a separate OAM interface that doesn't use file descriptors (at the application level), having to use ioctl(2) all of a sudden is... well... odd. Likewise for regular read/write. Just for boot code do we need o worry about mapping GEOM names to device special files. o XML is ideally suited for any and all kinds of data. Since all of the information related to GPART is obtained through the confxml, it seems inconsistent to not have the boot code obtained in that manner. To me it becomes a question of inconsistency vs inconvenience and inconsistency is always worse. o geom_getxml(3) allocates 1MB up-front for the XML. Either the XML is in that order of magnitude, in which case up to 10KB or so for boot code is insignificant, or 1MB is way too large and we have plenty of room for 10KB of boot code. Either way, it looks like it was envisioned that the XML can be large. How inconvenient can 10KB be, objectively, I wonder. -- Marcel Moolenaar xcllnt@mac.com