Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've always found it daunting and confusing how an OS hacker sets up their workflow. As a web-developer I find it easy to set up a workflow because web-sites run on servers and as such my OS is never touched. But an OS programmer, how do you do it? Do you develop on one machine and then somehow transfer code to the other machine? Do you develop on the OS you are developing, that last option seems rife with paradoxes? So how you do it?


My similar Quora question still has no answer to this question...

share|improve this question
I'm confused by your question. Do you mean systems programming for OS or maliciously hacking an OS? – Pubby Oct 18 '11 at 13:05
@Pubby8 My assumption is programming an OS based on the term "hacked on" instead of just "hack" in the title. – Jetti Oct 18 '11 at 13:26
It's the media that have made "hack" a malicious term, when infact it's "crack" that is the malicious one. – badgerr Oct 18 '11 at 13:48
Please see this link if you want to get into it: This website is an amazing resource for hacking around the linux kernel – CamelBlues Oct 18 '11 at 17:44
I mean it as in 'programming'... – Victor S Oct 18 '11 at 19:09
up vote 7 down vote accepted

I've never poked at Plan 9, but for Unix-type OSes (Linux, BSD), I just setup a system running the kernel I want to hack on, get the compiler toolchain installed (not very difficult on most modern Linux distros), and start building kernels.

If I'm fooling with the kernel itself, I rig the boot setup menus (grub or whatever I'm using) to have an extra option for my dev kernels, and reboot into the kernel under development.

For hardware hacking it's a bit easier, as I usually work with loadable modules, and so I can just load and unload the module I'm developing.

Debugging isn't the easiest thing in the world when working on the kernel, but that's when you learn to read the system log files.

share|improve this answer
Thanks, that should help get me started. – Victor S Oct 20 '11 at 12:53

Ever since virtual machines like VMWare, KVM/Qemu or Virtualbox are widely (and freely for most) available, the job has become a lot easier.

Before that, boot managers like GRUB or LILO allowed control over what binaries to boot on (allowing you to keep at least one 'stable' OS on your machine).

I guess that before that, you'd have to dedicate a whole machine for your developments.

share|improve this answer
Good point, wish I could aggregate this answer with the Michael's. – Victor S Oct 20 '11 at 12:54

While I don't do this personally, it seems like what would make the most sense is using a Virtual Machine (such as VM Player). This would allow you to make changes right away and then fire up the VM and load it to see those almost immediately instead of having to go through the whole process of putting it on a separate machine.

share|improve this answer
Agreed. Your build process should output a disk image that you can boot with qemu. When I worked on RMoX, that was what we did. – Edward Bowles Oct 18 '11 at 13:18
It also removes any chance of major screw-ups bricking your workstation. – World Engineer Oct 18 '11 at 13:32
@World Engineer: linux is not that easy to be screwed unless that's your intention because 1) you can have multiple kernels in multiple separated files; 2) chroot can be used to isolate other normal files. If you want to modify a kernel code and see how it behaviors, just compile it into a new kernel and load this kernel from boot loader. If it crashes, reboot and load the old kernel. I don't see how could that process screwing up your system. – Codism Oct 18 '11 at 16:32
@Codism - never underestimate the powers of a noob! – Jetti Oct 18 '11 at 17:04

The traditional way to do low-level hacking - I assume we're talking about the likes of device drivers - was to have 2 systems connected by a debug cable. This approach is still used to various degrees when developing embedded systems, although emulation and virtualisation make this largely a niche approach now.

The debug-cable approach means the controlling machine can inspect memory/registers on the slave even if the OS is in an unusable state - really valuable in some circumstances. JTAG debugging can take you even further, but I that's drifting off-topic into embedded systems.

share|improve this answer

The easiest and fastest way to do it nowadays is to use a virtual machine. Regarding Plan 9, even though it can be installed on QEMU, its distributed nature can only be exposed by using a client (computer with limited computing and disk space capabilities) server (multicore CPU server, huge capacity file server, etc.) organization.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.