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 18:10:08 UTC
On Sun, Jan 16, 2022 at 8:59 PM Aryeh Friedman <aryeh.friedman@gmail.com>
wrote:

> It was/is off topic to discuss the motivations on the design I have in
> mind but after thinking for it over 10 years (and using FreeBSD to build a
> IaaS around bhyve) I have come to the conclusion that *NO* existing OS can
> meet the design requirements I have in mind.
>
>

If you say this , it is understood that you are on the correct path .
Please continue .
My understanding was based on your  "(mostly for fun)"  phrase.
I beg your pardon .



With my best wishes for all , and additionally success in your efforts .

Mehmet Erol Sanliturk








> On Sun, Jan 16, 2022 at 11:13 AM Mehmet Erol Sanliturk <
> m.e.sanliturk@gmail.com> wrote:
>
>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>