Date: Sat, 09 Jun 2001 14:32:23 -0700 From: Mike Smith <msmith@freebsd.org> To: tlambert2@mindspring.com Cc: "Daniel C. Sobral" <daniel.sobral@tcoip.com.br>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Doug Denault <doug@safeport.com>, Greg Lehey <grog@FreeBSD.ORG>, developers@FreeBSD.ORG, FreeBSD Stable Users <freebsd-stable@FreeBSD.ORG>, FreeBSD current users <FreeBSD-current@FreeBSD.ORG> Subject: Re: FORTH: Modifying loader... Message-ID: <200106092132.f59LWN701157@mass.dis.org> In-Reply-To: Your message of "Sat, 09 Jun 2001 09:54:34 PDT." <3B2254CA.9FB93387@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
<variable>'. 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106092132.f59LWN701157>