Not everyone writes code for a critical Linux-based life support system. Very often it's just people who want to have a 7-segment LED display show the number of

Not everyone writes code for a critical Linux-based life support system. Very often it's just people who want to have a 7-segment LED display show the number of unread emails, or get a soundcard running, something along these lines. And for them it's completely ok that there's a race-condition that might crash their machine if the kernel-module is unloaded just at the instant where the USB plug is removed -- that's something to learn, once the general grasp of how kernel-code with it's myriad of callbacks and hierarchies of subsystems has been reached. Most crashes also will be catched by the Kernel and will leave you with nothing more than a [42568.139488] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 [42568.139805] IP: [<ffffffffa003e008>] init_module+0x8/0x20 [my_dummy_module] [42568.140308] PGD 4450f067 PUD 4450e067 PMD 0 [42568.140882] Oops: 0002 [#1] PREEMPT SMP (...) in your dmesg, and maybe a dead "insmod" process in your process table. Make a note of the call trace, sync, reboot (maybe hard, using the magic sysrq key) and you are off for the next round of debugging. Try it, it's fun. Also there's kgdb which you can use when your bugs aren't that obvious. I never had serious data loss (maybe the freshly compiled .o files will have 0-size, if I was in too much of a hurry to insmod ./my_module.ko. And even if, it will teach you to have an easily restorable development machine. (I triggered the oops with...) int init_module(void) { int *ptr = 0x0000000000000004ULL; *ptr = 17; return 0; }