On Sat, Jan 15, 2022 at 1:54 PM Bakul Shah 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
> 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
supplieddevice 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
