http://lwn.net/Articles/88767/ This is a special feed containing comments posted to the individual LWN article titled "Fear of the void". hourly 2 http://lwn.net/Articles/101659/rss 2004-09-11T09:34:03+00:00 jbglaw This adds a lot of bloat. First, you introduce an own alloc and free function for each used struct. And further more, you completely break what was intended: to check pointers that were passed along from generic subsystem code. These are shipped as void * pointers, and void * always "works" with other non-void pointers...<br> http://lwn.net/Articles/101658/rss 2004-09-11T09:29:04+00:00 jbglaw Private data structures are mostly allocated at driver load or open time, so I guess there's not much of a performance penalty.<br> <p> However, you need to keep the magic number around, too, so the kernel again gets a bit larger. You'd say this is unneeded bloat, since kernel code should be error free :-)<br> http://lwn.net/Articles/90569/rss 2004-06-22T12:46:46+00:00 steve_rotolo Consider the following interface:<p> struct funky; // forward decl<p> struct funky * funky_alloc (void);<p> void funky_dealloc (struct funky *);<p> int funky_dowhatever (struct funky *);<p>No magic, just C. The structure is private. All the user sees is pointers but the pointers are typed so the compiler can do the &quot;magic&quot; checking. Keep it simple.<br> http://lwn.net/Articles/89879/rss 2004-06-17T09:25:39+00:00 jae In the light of recent kernel vulns:<p>How much performance does this suck, or rather, how much would it cost if the global allocator would support this scheme?<p>If it's not too expensive (might well be, I don't read lkml), wouldn't it be better to use it and get a bit more safety into the kernel?