Date: Sun, 03 Aug 1997 17:25:39 +0800 From: Peter Wemm <peter@spinner.dialix.com.au> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: bde@zeta.org.au (Bruce Evans), phk@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/boot/biosboot Makefile Message-ID: <199708030925.RAA17139@spinner.dialix.com.au> In-Reply-To: Your message of "Sun, 03 Aug 1997 18:29:33 %2B0930." <199708030859.SAA13502@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith wrote: > Bruce Evans stands accused of saying: > > >> Modified files: > > >> sys/i386/boot/biosboot Makefile > > >> Log: > > >> Oops, boot2 got too big. make VESA_SUPPORT nondefault. > > > > > >Argh.. This really sucks. We REALLY should go to a multi-stage boot > > >somehow. > > > > Enlarging the existing boot would be much simpler. > > I disagree. Likewise.. Otherwise it'd have been done by now. > > New features are missing from cdboot, dosboot and netboot. > > And this is why. biosboot/cdboot/dosboot/netboot should be as small > as is feasible to allow them to fetch the single, common third-stage > bootstrap. I was about to say this too. Things are going to get messier when it comes time to deal with ELF symbol tables etc. However, there are not an awful lot of things that are "identical" between the different boot methods. But it would be a hell of a lot simpler to keep them all up to date if we have common code that has adapts to the boot method, eg: only set up network boot stuff when booting with network filesystems. For example, one should be able to boot from floppy, but with network filesystems and network swap etc. Putting all the network stuff in netboot is an unnecessary restriction. We need to not have to worry about the size of the boot code. It would be ideal if we could move some of the "one time only" stuff out of locore and into the stage3 boot. That way, we can more easily reclaim the memory after boot since the locore.s bootstrap code won't be in the middle of the kernel text. The point about the vulnerability of "/boot" or "/stand/boot" is valid, but it doesn't have to be "locked in" as such. If the stage2 boot for fd/ hd goes on a diet, there's not a lot of reason why it can't do a bios keyboard read or whatever and initialize enough things so that it can ask for an alternate stage3 path. I would expect that this would be pretty much essential for development/testing purposes anyway. It seems quite a few things use this method.. (ie: hold down key 'x' during boot to pop up a menu). On the plus side, you are no longer risking destruction of your fdisk/ disklabel tables in order to update the bootblocks since they would rarely change after boot3 was implemented. Loss of partition tables is far more disastrous than loosing /boot. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708030925.RAA17139>