Date: Sat, 09 Jun 2001 09:54:34 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Daniel C. Sobral" <daniel.sobral@tcoip.com.br> Cc: 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: FORTH: Modifying loader... Message-ID: <3B2254CA.9FB93387@mindspring.com> References: <50104.991592939@critter> <3B208329.2E2BFF2B@mindspring.com> <3B20BF6F.7060900@tcoip.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
"Daniel C. Sobral" wrote: > Actually, > > : Short-Appplication ." Hello World!" cr ; > > might even work... :-) 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? 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'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. We could guard the code against extending the file, and that's enough to ignore the allocation problems without damaging any FS to which it is applied, since we would only rewrite existing disk blocks. The "fread" verb already returns the exact length of the file, so that's not a problem, either. So do we have a BIOS write hacker and a FORTH hacker in the house? Worse comes to worse, I can find a sacrificial disk and do the BIOS write stuff myself, if I have to. Modified code for libstand to go back to CMU Mach, per the request, of course... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B2254CA.9FB93387>