Date: Mon, 10 Dec 2012 02:56:38 -0500 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: FreeBSD Mailing List <freebsd-hackers@freebsd.org> Subject: Re: using FreeBSD to create a completely new OS Message-ID: <CAGBxaXmRdc166NwG%2B38jM5F1vEgxtiu-52-P4q8GeR5mbfH80A@mail.gmail.com> In-Reply-To: <CACpH0Mfj77ccSOeeoaQfYtvXAWB_=gsJMKK7WoFckj%2BdJotggw@mail.gmail.com> References: <CAGBxaX=y9yLBymKX8Psmer0sPFWCgAFy3gs%2BtgU7waQt2g6hKA@mail.gmail.com> <CACpH0Mfj77ccSOeeoaQfYtvXAWB_=gsJMKK7WoFckj%2BdJotggw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 10, 2012 at 2:38 AM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote: > On Sun, Dec 9, 2012 at 11:48 PM, Aryeh Friedman > <aryeh.friedman@gmail.com> wrote: >> For personal hobby reasons I want to write an OS completely from >> scratch (due to some aspects of the design no existing OS is a >> suitable starting place)... what I mean is I want to start with the >> MBR (boot0) and go on from there... I only have one *REAL* machine to > > Well... most would say that the interesting part of an OS has very > little to do with the loader, but who am I to judge: maybe a loader is > interesting for you. There are quite a few things that can be loaded > and useful from an MBR. Pretty much any machine will provide you with > a boot environment that has lived longer than any other. It's pretty > much DOS without a filesystem, tho. In freebsd, you want to look at > /boot/mbr and maybe (later) /boot/loader (or one of it's variants). I was asking how to extract it from the virtual HDD made by vbox > >> work with which means I need to work with something like >> emulators/virtualbox-ose... I also want to do as many automated tests >> as possible (for example seeing if the installer copied the MBR [and >> later other stuff] correctly to the virtual HDD).... for this reason I >> have a few questions on vb (or perhaps QEMU if not possible in vb): >> >> 1. Can it be scripted? >> 2. Is there any documentation on the various virtual HDD formats and >> such (that way I can check the "physical" drive and not by indirect >> query)? > > The format of an MBR (master boot record) is documented everywhere. > I'm pretty sure wikipedia has a good article on it. This mailing list > is not google, BTW. I know (about the list not being google) and have seen the formats for MBR's (even wrote a few by hand) the question was how to extract it from the virtual HDD (see above).... namely is I have a prototype MBR that should be made I want to check if it was actually written to the virtual HDD correctly > >> Also can people give me some idea of a good general >> development/testing framework.... the one I have in mind so far is: >> >> 1. Write enough of the OS in FreeBSD to boot and give a command prompt >> and then develop using it (assume that there is a working compilor >> [note I am doing it completely in Java (note 1) and will be using >> either gjava (gcc) or writing my own compiler]) >> >> Notes: >> >> 1. Due to OS's needing to address physical RAM directly (DMA mapped >> I/O) I will be introducing some form of ptr's into java with the >> compiler or native > > My first thought was the humor of getting java to deal with segment > registers. It's hard enough in C. > > But in all seriousness, most systems go from the firmware to something > like a bootblock (often called a stage one boot) to a smarter > bootloader (stage two boot) to activating the OS. In a PC-ish world > for FreeBSD, that's BIOS->/boot/mbr->/boot/loader->kernel. > Specifically locore.s (note: assembly language file). locore.s is one > of a few regions of kernels that are generally _not_ written in high > level languages. Other's include the very lowest level of the > scheduler and the virtual memory manager. In locore's case, you can't > express the special instructions (for a PC) to exit real mode and > enter virtual mode (or some such transformation --- I really haven't > been there in awhile). Note that FreeBSD boots on a number of things > and that each boot process is a little bit different. The idea is not replicate *ANY* existing OS but write a completely new one (completely new architecture for an OS even). For that reason starting with the MBR is the right thing to do for reasons that would take several pages to explain. >From my initial research there is almost nothing that depends on actual ASM except for a very small number of things that create the environment needed to run the equiv of the JVM (no garbage collection at this level) natively on an x86. My guess the total amount of ASM needed is less then a thousand instructions (99% are macro's mostly for performance reasons). The other 1% is just to get the protected mode and the native JVM loaded and started. Note when I say JVM I actually mean a collection of VM's that model real HW (not some abstract HW like the sun JVM does) and if the VM just happens to be identical to the native HW then it skips the emulation part of the VM (i.e. direct execution on the actual HW). The first such VM I am planning is x86 (64-bit). Namely if your running on a PC then it runs natively but on anything else it runs on a VM identical to a PC. > > If you're going to write an OS from scratch, you might start with > something _way_ simpler than FreeBSD. Minix would be a good choice. > I think it still comes as a book you buy with bootable code. If you > haven't done OS work before, the book part might get you going faster > than diving into the FreeBSD codebase. I have done some trivial OS stuff before like getting to the point where I can type the equiv of ls and cd on a trivial virtual FS.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXmRdc166NwG%2B38jM5F1vEgxtiu-52-P4q8GeR5mbfH80A>