Jeff Dike wrote:
> I would also appreciate suggestions on what sort of memory access state table
> to implement, and where best to put the declarations. What I'm not clear
> on is what sort of access a buffer should have when it's in the care of
> the allocator (i.e. it's free). If the allocator sticks information
> temporarily in the buffer, then that needs to be stated.
Probably there will be some benefits, at least for a while, if valgrind for UML
"knows" the kernel allocators like valgrind for applications "knows" malloc+free.
Implementors of allocators can have bugs in the valgrind declarations they add.
An "independent" check based on documented externally-visible behavior can help.
Nested allocators (inner allocator grabs a large region, outer allocator performs
sub-allocations of small pieces from the large region) can be troublesome.
Implementing a four-state status {-, W, RW, RO} might be much more work,
because some accounting schemes are oriented naturally towards only three states
{-, W, RW}. Also, there are contenders for two additional states: watchpoints
for READ and WRITE, such as "any read of a back-pointer of this doubly-linked
list", etc.
-- John Reiser, jreiser@BitWagon.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:27 EST