From owner-freebsd-stable Sat Jun 9 14:23: 0 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1BC7737B401; Sat, 9 Jun 2001 14:22:42 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f59LWN701157; Sat, 9 Jun 2001 14:32:23 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200106092132.f59LWN701157@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: "Daniel C. Sobral" , Poul-Henning Kamp , Doug Denault , Greg Lehey , developers@FreeBSD.ORG, FreeBSD Stable Users , FreeBSD current users Subject: Re: FORTH: Modifying loader... In-reply-to: Your message of "Sat, 09 Jun 2001 09:54:34 PDT." <3B2254CA.9FB93387@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2001 14:32:23 -0700 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I've been waiting for a FORTH-geek to pop his head up; I > have most of "nextboot" reimplemented... I've added "fwrite" > and "flseek" verbs. I've thought about kidnapping an > astronomer. 8-). > > The current problem is that the biosdisk.c doesn't contain > "write" code, and that the libstand code wouldn't call it > if it did. > > I'm not really interested in creating or extending files, > and with those restrictions, it seems possible to do the > job. > > Is anyone interested in helping out with the code? I've wanted someone to fix the libstand filesystems to support overwrite for some time, so yes, I'd be happy to help here. > The basic plan is to take a file that has: > > "A A A B B B\n" > > and rewrite it as: > > "A A B B B A\n" > > (a rotor; slightly different than the original nextboot, > but acceptable, given the constraint of keeping the file > exactly the same length), and then use the first string > "A" (might be "disk1s1a:/kernel") to set curr_dev to the > "disk1s1a:" part, and then try to boot the "/kernel" part. I actually had a fairly different and more generic idea in mind; an 8k "boot.variables" file in /boot, which holds variables marked with 'save '. So you would do something like: set kernel_list="kernel.new,kernel.default,kernel.emergency" set kernel_index=0 save kernel_list save kernel_index to set things up. If the format of the file was sensible, manipulating it from userspace would be trivial as well. > I'll write the user space utility, and I'm willing to do > the UFS code as well, but it's been 15 years since I've > done FORTH, and I'm not too confident of the VM86 calls > in biosboot.c for writing, either. I can't help with the FORTH, but I certainly know what needs to be done in biosdisk.c. Note that the SRM equivalent can't write to the disk, so this *won't* work for the Alpha. 8( Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message