On Fri, 3 Apr 2015, Drokin, Oleg wrote:
> Hello! > > On Apr 2, 2015, at 6:18 AM, Julia Lawall wrote: > > >> Julia, I wonder if you happen to have a bunch of other patches to get rid > >> of the rest of OBD_ALLOC and OBD_FREE stuff by any chance? > > I can generate them again, but I wasn't clear on what was wanted. I would > > really prefer something where it is explicit at the call site that an > > assignment is taking place. If we can have x = obd_alloc(...) and > > obd_free(x,...) (I don't have time to look up the exact arguments at the > > moment), then I can take care of that). I still think it is too bad that > > this code won't benefit from rules written for more generic memory > > allocation functions, but if the extra debugging facility provided by > > these functions is useful, then I guess it is reasonable to keep it. > > Like I mentioned sometime last year - it's now pretty easy to replace the > memleak > detection with other in-kernel mechanisms some of which are in fact even > better > than what we have. And considering our mechanisms are totally broken now by > the mixup of > wrapped vs nonwrapped allocation/freeing - there's no point in holding to it > remaining at all. > The only last bit of useful functionality left, I imagine, is the ability to > redirect allocation > to regular kmalloc or to vmalloc based on the allocation size (there's kvfree > already for the > freeing part of it). > Other than that the wrappers could go away at any time now, I think. OK, thanks. julia _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
