Date: 03 Dec 1998 11:52:47 -0600 From: Joel Ray Holveck <joelh@gnu.org> To: Robert Nordier <rnordier@nordier.com> Cc: mike@smith.net.au, jkh@zippy.cdrom.com, Marius.Bendiksen@scancall.no, hsw@email.generalresources.com, hsw@acm.org, abial@nask.pl, freebsd-current@FreeBSD.ORG Subject: Re: /boot/loader what to set rootdev to? Message-ID: <86btllqfio.fsf@detlev.UUCP> In-Reply-To: Robert Nordier's message of "Thu, 3 Dec 1998 13:13:48 %2B0200 (SAT)" References: <199812031114.NAA15654@ceia.nordier.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Yes, we have been over this before. Would you care to explain how you >>> plan to reinstate the vectors that the DOS7 kernel replaces so that >>> vm86 BIOS calls from the FreeBSD kernel will work? >>> Please understand that there are some really fundamental issues which >>> absolutely preclude starting FreeBSD once DOS has been started. >> We may have a different definition of "DOS7 kernel". I typically use >> that phrase to refer to IO.SYS alone. The vectors seem to be modified >> by HIMEM.SYS instead. By default, IO.SYS will load HIMEM.SYS and >> prevent the kernel from loading. However, the line "DOS=NOAUTO" in >> the config.sys will cause IO.SYS to skip that step. I have had >> success loading FreeBSD by using that line in the PIF's specified >> CONFIG.SYS myself. > As you go on to describe, it is *not* particularly difficult to > boot FreeBSD straight out of Windows. I want to make one point clear: the process *does* have an intervening reboot between when Windows is loaded and when FreeBSD is loaded. > However, the reason we don't want to actively support this is that > it makes the kernel vm86 mechanism unreliable. Interesting. I had vm86 problems using the system before adding NOAUTO, but since then, I've been using it fine. I'm not saying it would work for everybody, just that I don't have enough information to find where it fails, which is something I'm interested in. Which vector is in question? I thought it was 15h, but when I looked, that was apparently still mapped to the BIOS just before FBSDBOOT is loaded. > I researched the whole issue in really exhaustive detail, a year > or so ago, before off-list discussions with Mike Smith, which led > to the decision not to support any kind of FBSDBOOT approach in > the new boot code project. Okay. I'm still curious about your findings. Did you write up anything on it? > What we can support with little trouble (if any Windows programmer > wants to step forward to do the actual Windows coding) is the following > completely safe method: > In Windows, have a FreeBSD control panel which allows you to > point and click on FreeBSD slice, and set any of the standard > boot block options like -s (single user) or -v (verbose). When > the user clicks "Go" (or whatever), the Windows application > communicates with the boot manager through an API, then does > a cold boot. The partition manager gets control, and passes > the selected parameters to the boot blocks, which may also pass > them on to /boot/loader, as required. Sounds like a good thing to do. Does the nextboot API still work? How can I test this? If there is some sort of problem and the vectors in question are not reset to the BIOS, it apparently doesn't seem to affect my normal operations. Is there something I can check, or some procedure which would regularly fail, so I can know if it doesn't work? Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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?86btllqfio.fsf>