Hi! > > And sure, your free() implementation obviously also has that property, > > but I'm worried that they might one day decide to warn about the > > prototype mismatch (actually, I'm surprised it doesn't warn now, given > > that it obviously pretends to know what free() function I'm calling...), > > or make some crazy optimization that will break stuff in very subtle ways. > > > > Also, we probably don't want people starting to use free() (or whatever > > name is chosen) if they do know the kind of memory they're freeing? > > Maybe it should not be advertised that widely (i.e., in kernel.h). > > All that you've said I see as an advantage, not a disadvantage. > Maybe I should change the prototype to match the userspace > free(), although gcc is deliberately lax about the constness of > function arguments when determining compatibility with builtins. > See match_builtin_function_types() if you're really curious. > > gcc already does some nice optimisations around free(). For example, it > can eliminate dead stores: Are we comfortable with that optimalization for kernel? us: "Hey, let's remove those encryption keys before freeing memory." gcc: :-). us: "Hey, we want to erase lock magic values not to cause confusion later." gcc: "I like confusion!" Yes, these probably can be fixed by strategic "volatile" and/or barriers, but... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
