Date: Fri, 10 May 2002 10:22:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Jonathan Mini <mini@freebsd.org>, Michael Smith <msmith@mass.dis.org>, Gordon Tetlow <gordont@gnf.org>, hackers@freebsd.org Subject: Re: nextboot loader diff Message-ID: <3CDC01ED.A188796F@mindspring.com> References: <200205091911.g49JBaI3002178@mass.dis.org> <3CDAF1A6.13DB883D@mindspring.com> <20020509151603.F43682@stylus.haikugeek.com> <3CDBE300.2AED36C2@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > > Maybe you could ask Archie or Ambrisko to clarify the feature > > > you're trying to replace, and then ask Mike about the code > > > needed to do that? > > ehem.. > WHO wrote that? > :-) Me. My memory sucks for the time before I was there... ;^). I thought it was Archie and Doug. > My original aim was to allow a system to boot successfully using a > sequence of possible specifications, assuming that one of the filesystems quoted > (possibly the first) was so trashed that you couldn't read any files from it. > > You also had to have: > 1/ a way of setting the boot specification list from the running system. > 2/ a simple and unlikely-to-break method of ensuring that if the boot did NOT > succeed, it did something DIFFERENT next time. > 3/ the ability to read the specification information regardless of the state > of the first filesystem (e.g. completely trashed). > 4/ The ability to specify a filesystem on another planet^H^H^H^H^H^Hdisk. > > Unfortunatly I couldn't get away from having the boot1 on the first > disk, but possibly that could be fixed too. At least the boot1 code is not in > the filesystem itself and therefore hopefully less likely to be trashed. The boot0 stuff is "just another filesystem". Topologically, I think, ther eis really no difference. It's trying to "make B safe by using A instead"... which doesn't "make A safe as well". > My decisions were: > A) make boot0 do the actual load of the spec from block1 immediatly after it > had read block0.. All teh registers were set up correctly to read the next > block. > block1 is almost alway unused, and if it was used it wouldn't have the correct > magic numbers and would be ignored. This is really not an option any more. The block is used, and there is no free reserve space (the new 3.1 tools bloat the code up 96 bytes more than will fit, actually). > B) If the magic numbers matched.. > Copy the first spec string, skipping initial NULLS to above the top of the > stack, > for retreival by boot1 (it could get at it as if it were an argument) It's actually just as easy to make boot1 go read it itself, assuming boot1 has the ability to read. It also decouples it somewhat, which (IMO) is a good thing. This is actually the same effect they get from using a seperate file, which gets rewritten, rather than hacking "YES" vs. "TRY" vs. "NO" in a common .conf file (which makes me incredibly nervous, just like Mike's complaint about it). > C) ZERO out that string, now the NEXT string is the first string. I personally don't like this. You were able to get away with this because, once empty, the boot code fell back to non-"nextboot" behaviour. In any case, you would be in an infinite reboot cycle, so it would not save you. The only thing that would maybe save you is if the the default for boot0 in the case of an empty list with a *seperate* enable bit, would ATX power off the machine (voluntarily turn into a doorstop, instead of waiting for abnormaly wear to turn you into a doorstop whether you wanted it or not). The same effect is achieved by pushing the list on a stack, popping the head, and adding it to the tail, using the head as your device. This has the added advantage of keeping the file length the same, so that the FORTH fwrite doesn't have to learn about extending or truncating files, so that the linbstand FS code can remain much less complicated than it would otherwise have to be. 8-(. > D) write the block back using the same registers, while still in boot0. We tried this as well. After hacking out about 160 bytes of data, and using the old (4.4) toolchain, which didn't bloat the code like the 3.1 toolchain seems to do, we had enough space left to make the assembly code self-modifying to be able to toggle the BIOS code between "read" and "write"... which let us put it in the boot code in the boot sector, rather than in the boot code that had to be read out of the FS itself (we were trying to revive your design). But the complexity of doing this was too high, and the patient died. Even had we been entirely successful with this approach (nowhere to write the data, now that we can write it), I think we would have scrapped it, because it would have made the code very, very difficelt to understand (what with it hacking INT 13 arguments around in the code, and dealing with carry examination x86 instructions). It would have also lost us one of the greatest benefits of the FORTH code, which is the portability of things like this to other platforms. > E) Boot1 retrieved the string from the stack. Yeah, that's not incredibly relevent. With file I/O, the same information can be read from a file by the FORTH interpreter, and it's real easy to break the string list with space seperators into elements, the first of which is stores seperately, the remainder of which is pushed on a stack, and the popped, seperate storage added, and then written back out. It can all take place in the moral equivalent of "boot1", but in a way that's a lot more portable for Alpha, PPC, SPARC, etc.. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CDC01ED.A188796F>