From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] changes in 9load Message-ID: <20030521200315.H7647@cackle.proxima.alt.za> References: <90b20611bddbc6da6a3a70d5d136263a@plan9.bell-labs.com> <237a8d9fe4cca979898acf08a7987cb1@plan9.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <237a8d9fe4cca979898acf08a7987cb1@plan9.escet.urjc.es>; from Fco.J.Ballesteros on Wed, May 21, 2003 at 07:39:57PM +0200 Date: Wed, 21 May 2003 20:03:16 +0200 Topicbox-Message-UUID: b6d489da-eacb-11e9-9e20-41e7f4b1d025 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