From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: Fco.J.Ballesteros To: 9fans@cse.psu.edu Subject: Re: [9fans] changes in 9load In-Reply-To: <20030521200315.H7647@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-kridoghykomvfjvffxibweahiw" Date: Wed, 21 May 2003 20:11:36 +0200 Topicbox-Message-UUID: b6dc771c-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-kridoghykomvfjvffxibweahiw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The point it that it would be yet another place where you have to put configuration in. If configuration doesn't go away (eg by putting it in the thing being handled, like in the disk used by venti), I prefer to keep it all just in one place. I mean, If right now, if I get 9load and a plan9.ini, I'm all set. --upas-kridoghykomvfjvffxibweahiw Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Wed May 21 20:08:02 MDT 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 0D05919C3B; Wed, 21 May 2003 14:05:14 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 7858419C3C for <9fans@cse.psu.edu>; Wed, 21 May 2003 14:04:24 -0400 (EDT) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.9/8.12.3) with ESMTP id h4LI3Gnp029056 for <9fans@cse.psu.edu>; Wed, 21 May 2003 20:03:17 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.9/8.12.3/Submit) id h4LI3G8g029055 for 9fans@cse.psu.edu; Wed, 21 May 2003 20:03:16 +0200 (SAST) From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] changes in 9load Message-ID: <20030521200315.H7647@cackle.proxima.alt.za> Mail-Followup-To: 9fans@cse.psu.edu References: <90b20611bddbc6da6a3a70d5d136263a@plan9.bell-labs.com> <237a8d9fe4cca979898acf08a7987cb1@plan9.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <237a8d9fe4cca979898acf08a7987cb1@plan9.escet.urjc.es>; from Fco.J.Ballesteros on Wed, May 21, 2003 at 07:39:57PM +0200 Organization: Proxima Research & Development Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 21 May 2003 20:03:16 +0200 On Wed, May 21, 2003 at 07:39:57PM +0200, Fco.J.Ballesteros wrote: > > I meant a file system to access the /boot portion in the kernel image. > But I think that's both clumsy and wrong (because you might change the kernel > without doing a mk) and discarded the idea soon after considering it. I don't like the thought of manipulating a disk image in this fashion, myself. But I really think your objective could be achieved, as you point out, by storing the information in a config file _other_ than plan9.ini on the boot medium. Maybe a /n/init mountpoint? Would this really be less flexible than having the knowledge in 9load? ++L --upas-kridoghykomvfjvffxibweahiw--