Re: Using bhyve to develop and OS -- tips on how?
Date: Sun, 16 Jan 2022 17:59:00 UTC
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. 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