Re: Using bhyve to develop and OS -- tips on how?

From: Mehmet Erol Sanliturk <m.e.sanliturk_at_gmail.com>
Date: Sun, 16 Jan 2022 16:13:06 UTC
On Sat, Jan 15, 2022 at 1:54 PM Bakul Shah <bakul@iitbombay.org> wrote:

> You may be better off using qemu, at least initially as “legacy” booting
> requires jumping through a few more hoops. Another suggestion is to check
> out wiki.osdev.org. There are a lot of useful resources on this site.
>
> On Jan 15, 2022, at 1:29 AM, Aryeh Friedman <aryeh.friedman@gmail.com>
> wrote:
>
> 
> I want to develop a OS completely from scratch, i.e. starting with the
> first instruction encountered after POST and everything above it (mostly
> for fun).
>
> I want to use bhyve to do this any tips on how to get started (I have
> found a few tutorials on how to do the asm part of a MBR but that's about
> as far as I have gotten).
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>
>

Dear Aryeh ,


https://wiki.osdev.org/Required_Knowledge

From the beginning of above page :

"
Required Knowledge

If you think you can skip this, it's probably just for you.

Writing an OS is not a beginner's task.
In fact, writing an OS is usually considered the most difficult programming
task.
You will need above-average programming skills before even considering
a project like this. .....
"

If you want to take such a difficult road to pursue , you may do the
following :

Study the bug reports , or GSOC projects , or projects to be handled by the
FreeBSD Foundation
( or if you want more difficult problems , please search my mailing list
messages
to see "crazy" ideas , or please ask me "Do you have more crazy ideas ?" .
You may be sure that I can find much "more crazy" ideas for you based on my
goal to write
a NEW operating system mainly based on FreeBSD , but from SCRATCH for
( not "Very" but ) "Large scale software stacks (  distributed , expert
system based
meaning learning  , etc ... . ) )


If you confine your works on FreeBSD , if you want to be able to solve its
current problems ,
this will mean that you are knowing how to write an OS because you are
knowing
the FreeBSD very well and are able to modify it toward a more mature state .
At the end you will gain and FreeBSD will gain .


A few suggestions :

(1) Make a list of "panic" points .
     Eliminate as many of them as possible to protect the OS from crashing
by determining
     whether the next application step will cause a panic or not ( check
panic conditions
     before entering the next step ) and do not enter into it but return
safely back by taking
     necessary actions other than "panic" .

(2) At present many device behaviors are encoded into kernel related
routines
     such as internal tables , constants , etc. .
     Design a device definition  *.XML file format and move these internal
definitions
     into these files with file names generated from device characteristics
.
     For the detected existing devices and newly attached devices ,
generate the file
     name and search that file . If it exists , load it , else give a
suitable error message .
     This allows to add new devices by the users by using device producing
company
     supplied    device definitions  , or device definitions without
requirement of
     modifications of kernel related sources  .
     One more step would be to allow user supplied ( not "root" supplied )
device definitions
     and its associated device drivers loaded from userland .

      Such a system will be a very easy structure for the device producing
companies
      because already they have device driver software , it is very easy to
generate a
      device definition . The users will be able to use these devices
easily by only
      attaching the device , storing its device driver and definition file
into her / his space .

      This will attract the companies to be interested in FreeBSD , and
produce more
      such drivers , definitions .
      This will increase number of possible FreeBSD users now repelled back
due to difficulty of
      use of the devices or complete lack of their associated software
parts , by solving
      their problems .


It is possible to define many more improvement points .

If present problems are handled , they will inspire many new improvement
points
which means you may continue to contribute to FreeBSD as much as possible .

This will supply what you want to do and its very pleasing happiness ( with
respect to my
understanding of your intentions ) .



With my best wishes for all ,

Mehmet Erol Sanliturk