I started off with RedHat and then Ubuntu as my dev env. Dual boot with windows & ubuntu and developing my OS on ubuntu with VIM as the editor/IDE
In the last few months, I have changed my OS dev env. I develop on Windows using WSL2(Ubuntu), with CLion (IDE), CMAKE (build toolchain), and QEMU (using Xming on Windows)
Except for some boot/init stuff which is in assembly, the rest of the code is in C and C++(11). I am quite impressed with the latest CLion which lets me use cmake build toolchain and seamlessly integrate with WSL2
On WSL2 (Ubuntu) - which I think is pretty much like a VM - I am able to create/mount loop devices (for disk images), build gcc/g++ cross compiler with C++11 support.
Curious to know if anyone is using a similar configuration for their OS dev env. Please share what's your OS dev env setup looks like
OS dev on WSL/CLion
OS dev on WSL/CLion
complexity is the core of simplicity
Re: OS dev on WSL/CLion
That's close to what I use.
- I use WSL 1 (because WSL 2 has regressed network performance, and I use qemu in graphics mode for testing)
- My IDE is Visual Studio Code, which has built in WSL integration.
- My build system is using CMake with Clang.
Re: OS dev on WSL/CLion
I develop on Linux. My "IDE": vim. I use vim for everything. I use it at work, and at home, I have used it for C, C++, C# (on Windows, with the csc command line compiler), shell scripting, config files, Java (when I was younger), everything.
My build system: Shell script that creates a makefile. I eventually happened to land on that when I read someone describe that GNU Make essentially just tries to marry POSIX Make with POSIX sh. So why not just use sh? So I have a POSIX sh script that creates a POSIX make file. That stuff should be portable to anything POSIX, and even to Windows with nmake, but I don't want to make assumptions.Dependency tracking is done by the shell script (i.e. dependencies are not automatically updated). This (like everything else) has drawbacks and advantages. With GCC, spitting out the dependencies can be done on the fly, but at work I have a compiler where generating dependencies requires a second pass over the file, and it takes about as long as actually compiling it.
I might improve the script to create a ninja file instead in future. That's the nice thing about this setup: I haven't sunk so much time into a Makefile that switching to ninja is utterly unthinkable.
I typically run my OS against bochs, but I periodically try QEMU as well. A real hardware test has yet to happen. Partially because I put all my debug messages on serial line instead of the main screen, so the screen is free for userspace to use (and so I don't need a font renderer in kernel space). But it does mean I can only debug it if the computer I use has a serial line (and it has to be an ISA COM port, none of that USB rubbish ), and I have a terminal handy. The problem with USB serial adapters is that, ironically, USB has no standard for serial adapters, despite being called the Universal Serial Bus. So USB serial adapters usually use one of a handful of chips to do the translation, and each works completely differently, and in both cases, I have not seen data sheets detailing the use. So in the end, I would have to poach the drivers from elsewhere (like Linux), and then there's that legal stuff again.
My build system: Shell script that creates a makefile. I eventually happened to land on that when I read someone describe that GNU Make essentially just tries to marry POSIX Make with POSIX sh. So why not just use sh? So I have a POSIX sh script that creates a POSIX make file. That stuff should be portable to anything POSIX, and even to Windows with nmake, but I don't want to make assumptions.Dependency tracking is done by the shell script (i.e. dependencies are not automatically updated). This (like everything else) has drawbacks and advantages. With GCC, spitting out the dependencies can be done on the fly, but at work I have a compiler where generating dependencies requires a second pass over the file, and it takes about as long as actually compiling it.
I might improve the script to create a ninja file instead in future. That's the nice thing about this setup: I haven't sunk so much time into a Makefile that switching to ninja is utterly unthinkable.
I typically run my OS against bochs, but I periodically try QEMU as well. A real hardware test has yet to happen. Partially because I put all my debug messages on serial line instead of the main screen, so the screen is free for userspace to use (and so I don't need a font renderer in kernel space). But it does mean I can only debug it if the computer I use has a serial line (and it has to be an ISA COM port, none of that USB rubbish ), and I have a terminal handy. The problem with USB serial adapters is that, ironically, USB has no standard for serial adapters, despite being called the Universal Serial Bus. So USB serial adapters usually use one of a handful of chips to do the translation, and each works completely differently, and in both cases, I have not seen data sheets detailing the use. So in the end, I would have to poach the drivers from elsewhere (like Linux), and then there's that legal stuff again.
Carpe diem!
-
- Member
- Posts: 148
- Joined: Sun Aug 23, 2020 4:35 pm
Re: OS dev on WSL/CLion
I used to use an Ubuntu dual-booted with Windows 7, but recently I got a laptop with Windows 10, so I decided to try out WSL (Ubuntu 20.04).
It worked pretty well, so I use it as my main Linux for now. I had to update to WSL2 because I needed to be able to mount loopback devices.
I also run XLaunch (VcXsrv) so I can run graphical QEMU/Bochs, but it is a bit glitchy. For instance, it used to work without having to tick the "Disable access control" box every time. Also, it fails to change the mouse cursor or switch to free-look mode.
It is nice to not have to reboot every time I want to play Windows-only Steam games though, or use Windows Movie Maker (still), or run Unity (because the Linux version is pretty glitchy).
Unfortunately, WSL2 does not have support for lsusb (or USB pass-thru in general), so I can't test my USB code very well, and occasionally have to go back to booting a Linux VM.
For my "IDE", I usually just use Notepad++ (another benefit of using WSL2). I really like most of its key shortcuts, like Ctrl+D to duplicate a line (vs other IDEs which DELETE the line), Ctrl+Shift+↑/↓ to move a line upwards/downwards, etc.
I also like the ability to do a "search all in workspace" thing.
I know these features are probably available in other IDEs, but A) I really don't like terminal-only IDEs and B) Other IDEs are often slower and C) I like Notepad++.
If there were a fast IDE that had the Ctrl+D and Ctrl+Shift+↑/↓ shortcuts (or a way to remap something to them) and the "search all in workspace" thing, then I'd consider trying it.
I just use Make/GCC for my build system.
It worked pretty well, so I use it as my main Linux for now. I had to update to WSL2 because I needed to be able to mount loopback devices.
I also run XLaunch (VcXsrv) so I can run graphical QEMU/Bochs, but it is a bit glitchy. For instance, it used to work without having to tick the "Disable access control" box every time. Also, it fails to change the mouse cursor or switch to free-look mode.
It is nice to not have to reboot every time I want to play Windows-only Steam games though, or use Windows Movie Maker (still), or run Unity (because the Linux version is pretty glitchy).
Unfortunately, WSL2 does not have support for lsusb (or USB pass-thru in general), so I can't test my USB code very well, and occasionally have to go back to booting a Linux VM.
For my "IDE", I usually just use Notepad++ (another benefit of using WSL2). I really like most of its key shortcuts, like Ctrl+D to duplicate a line (vs other IDEs which DELETE the line), Ctrl+Shift+↑/↓ to move a line upwards/downwards, etc.
I also like the ability to do a "search all in workspace" thing.
I know these features are probably available in other IDEs, but A) I really don't like terminal-only IDEs and B) Other IDEs are often slower and C) I like Notepad++.
If there were a fast IDE that had the Ctrl+D and Ctrl+Shift+↑/↓ shortcuts (or a way to remap something to them) and the "search all in workspace" thing, then I'd consider trying it.
I just use Make/GCC for my build system.
My OS: TritiumOS
https://github.com/foliagecanine/tritium-os
void warranty(laptop_t laptop) { if (laptop.broken) return laptop; }
I don't get it: Why's the warranty void?
https://github.com/foliagecanine/tritium-os
void warranty(laptop_t laptop) { if (laptop.broken) return laptop; }
I don't get it: Why's the warranty void?
Re: OS dev on WSL/CLion
Use a config file.foliagecanine wrote: I also run XLaunch (VcXsrv) so I can run graphical QEMU/Bochs, but it is a bit glitchy. For instance, it used to work without having to tick the "Disable access control" box every time.
Skylight: https://github.com/austanss/skylight
I make stupid mistakes and my vision is terrible. Not a good combination.
NOTE: Never respond to my posts with "it's too hard".
I make stupid mistakes and my vision is terrible. Not a good combination.
NOTE: Never respond to my posts with "it's too hard".
-
- Member
- Posts: 148
- Joined: Sun Aug 23, 2020 4:35 pm
Re: OS dev on WSL/CLion
That's what I do now.rizxt wrote:Use a config file.
My OS: TritiumOS
https://github.com/foliagecanine/tritium-os
void warranty(laptop_t laptop) { if (laptop.broken) return laptop; }
I don't get it: Why's the warranty void?
https://github.com/foliagecanine/tritium-os
void warranty(laptop_t laptop) { if (laptop.broken) return laptop; }
I don't get it: Why's the warranty void?