From owner-cvs-src@FreeBSD.ORG Sun May 23 13:25:30 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0652516A4CE; Sun, 23 May 2004 13:25:30 -0700 (PDT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7779E43D46; Sun, 23 May 2004 13:25:29 -0700 (PDT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i4NKOqfQ084679; Sun, 23 May 2004 22:24:52 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i4NKOlc5084678; Sun, 23 May 2004 22:24:47 +0200 (CEST) (envelope-from marius) Date: Sun, 23 May 2004 22:24:47 +0200 From: Marius Strobl To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Message-ID: <20040523222447.M251@newtrinity.zeist.de> References: <200405221656.i4MGu50k062998@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from des@des.no on Sun, May 23, 2004 at 08:43:45PM +0200 X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.59; VDF 6.25.0.73 (host: newtrinity.zeist.de) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/eeprom Makefile eeprom.8 eeprom.c ofw_options.c ofw_options.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2004 20:25:30 -0000 On Sun, May 23, 2004 at 08:43:45PM +0200, Dag-Erling Smørgrav wrote: > Marius Strobl writes: > > The idea of eeprom(8) is that handlers can be written to add support > > for any firmware that stores such configuration in EEPROM or NVRAM; > > sort of e.g. eeprom(1M) on Solaris/x86 is used to turn PAE-support > > on and off (stored in a file then, not hardware). In FreeBSD, a > > candidate for this would be a handler for the EFI boot environment > > for FreeBSD/ia64. > > Would it make sense to teach eeprom(8) how to handle /boot/loader.conf? > My idea (which doesn't necessarily mean it has to come true) was a single utility with the same MI frontend for displaying and modifying MD configurations stored in hardware somewhere. The mention of eeprom(1M) on Solaris/x86 was meant as an example of precedence that a utility named "eeprom" already is in multi- platform use (the NetBSD one, too, btw., but only for their sun3* and sun4* ports). IMO teaching it about loader.conf would overload it at some point ("Hey, it already handles loader.conf, can we make it handle rc.conf, too?") and a separate utility for handling loader.conf or FreeBSD config files in general would be more appropriate. However, I don't feel like being the maintainer of the FreeBSD eeprom(8) so if others think it makes sense to teach it about e.g. loader.conf, why not.