On Wednesday 14 November 2001 20:52, Calin A. Culianu wrote: [...] > > the only way out is a reboot and check your cleanu_module function. > > Actually, it would be a cool exercise to write a module-cleaner-module > as a hack that basically undoes the kernel module structures and > kfree's the memory taken up by a module in the 'deleted' state. > However such a hack has stability implications as if that module did > anything non-trivial with any other kernel data structures.. VERY BAD > THINGS CAN HAPPEN. :)
Yeah, interesting thing to hack - but it's probably more worthwhile to study "typical C/C++ bugs" statistics, and figure out ways of avoiding most of them in though defensive programming. What makes this approach even more interesting is that some of these bugs don't always show up right away, but might "pop up" in a customer's system, long after the development stage is officially over. In short, defensive programming pays. Allways, I'd say. Note that I'm not talking about brute force double checking everything everywhere. That can indeed be useful, but the real gains lie in not creating the bugs that these checks will trap in the first place. Things like never ever writing "if(<variable> == <constant>)" where you can use the typo-trapping version "if(<constant> == <variable>)" instead. Simple rules like writing constructor/destructor code alternating between related construction and destruction statements, instead of writing the whole constructor first, *hoping* you'll get the destructor right afterwards. And a rule that perhaps applies to real time applications more than any other type of applications: Always, always, *always* set a pointer to NULL after freeing, decoupling or otherwise "getting rid of" the object it used to point at. You still get segfaults, but those are a lot easier to debug than the unpredictable effects of illegal references to objects that still exist, but belong somewhere else. (Just imagine what happens if you run some list operation on a node that's in the "free pool", and then wait until someone hits the point in the pool stack where that object used to be. Not fun! Then do that in kernel space... :-) Consistency also helps a great deal; for example, decide if you want objects to *own* other objects (ie create and free them themselves) or just reference them - mixing these styles without good reason is guaranteed to cause headaches. Sure, it takes some thinking to get it right, but "double deallocation" (which is not safely trapped in every environment!), memory leaks and use of "dead" object bugs take even more time to track down. Finally, if anyone knows about a serious and good source for more ideas and tricks along these lines, or has ideas and tips, feel free to mail me off the list. (This is getting off topic.) Maybe we could set up a "Safer C/C++ Programming" site somewhere? (I've got plenty of room at http://olofson.net.) I know there are some articles along the lines, but I've only seen fool-proofing of pointers with C++ "magic" and that sort of stuff. I'm more interested in approaches based on theory and philosophy; "tricks" that are applicable without restricting the flexibility of the language, or resulting in "weird" interfaces. //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -------------------------------------------------. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-------------------------------------> http://olofson.net -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
