OSDev.org

Hi everyone,

I am relatively new to OS development and am looking to do things in a sort of "best practices" sort of way, especially when it comes to maintaining my source code/build process. I started OS Development as a way to learn lower level (bare metal) concepts, and simply due to the fact that it is challenging and fun; yet I want to constrain myself to build/integrate/test my OS in a consistent manner.

I am picking back up on my project after a multiple month hiatus, and would like to possibly start from scratch (or from the scaffolding that I currently have in place). So... I am looking for some pointers to bring my build process together. I currently have:

• Windows running Hyper-V (Ubuntu) as the OS-DEV environment, with build tools
• Windows running Hyper-V (blank) as an install/run environment (OS-TEST)
• A set of windows i386 ELF tools for cross compiling.

As it stood/stands, I have the following process:

• [1] Connect to OS-DEV (if not using Win. ELF tools) and make any wanted changes to the source code.
  [2] Commit changes to the Repo
  [3] Build a .bin or .iso from OS-DEV and push to source repository
  [4] Pull the .bin or .iso from the source repository to Windows
  [5] Attach the .bin/.iso to OS-TEST
  [6] Test code changes

This all seems terribly inefficient. How do people manage their builds, source code, data (etc...) across their DEV, INTEGRATION, and TEST environments? Would it be best to stick to developing strictly in a Linux environment (abandon the Windows ELF tools)?

For those interested in the current state of the source code, the repository is:
http://www.github.com/lesniakbj/BrenOs

1) Use Bochs to test your OS. It has many tools to aid in debugging, and logs a lot of info that will help you track down issues.
2) Use a samba/network share to share your code between your os-dev vm and your main pc to prevent having to "download" your binaries everytime you want to test.

- Monk

I do my development and builds on the same machine, using Windows and MinGW/MSYS. This can be difficult to set up, but it's one way you could simplify your workflow. Of course, using Linux instead of Windows is an equally valid (and probably easier) option.

For tests, I use mostly real hardware, but also Bochs when I need to debug something. It's good to have at least one test PC, since virtual machines aren't perfect.

I have a VM with TeamCity on which runs automated tests using Bochs each time I push a code change. Though I only have a bootloader in my current iteration of OS development, so there's not much to test!

madanra wrote:I have a VM with TeamCity on which runs automated tests using Bochs each time I push a code change. Though I only have a bootloader in my current iteration of OS development, so there's not much to test!

What kind of tests do you have automated? This is somewhat what I want to do, make an automated build/test enviorment so I can get my OS tested thoroughly.

Thanks to everyone who has replied so far, I'm starting to lay out a development plan with your feedback.

I currently have automated tests for my MBR and ext2 VBR. They use the Bochs debugger to inspect memory contents and screen contents. The success test cases are things like booting from different partitions, and loading different file sizes. The failure test cases are things like there being no bootable partitions, or failing to read the disk, or the superblock being invalid. The tests run both locally on my machine and on TeamCity. I'm hoping to open source the bootloaders (and their tests), but I haven't had a chance to do anything OSDev related for a few months. I can go into more detail if you like.