On Mon, 10 Dec 2001 Andries.Brouwer@cwi.nl wrote:
> From viro@math.psu.edu Mon Dec 10 17:50:02 2001
>
> Basically you propose to take the current system, replace it with
> something without clear memory management ("let it leak") and then
> try to fix the resulting mess.
>
> Al - you are using debating tricks instead of logic, using
> negative words ("unclear", "leak", "mess") instead of arguments.
> Maybe you are unable to refute the soundness of the system I propose?
<blink>
> It is quite possible that I overlook some detail.
> On the other hand, I have been running these systems.
> You are not able to convince me that something is wrong
> just by handwaving. Real arguments are required.
> What I do is go from the present situation, in a series of steps,
> to a new situation where the source looks different but the
> system behaves provably the same. Consequently, no "fixing"
> is required. "Mess" is a matter of taste, I'll not discuss that
> except by saying that I vastly prefer the situation without arrays.
> "Leak" is false. "Dangling pointers" is false.
What??? You've just said that on the first stage you are not going to
free these objects and then add freeing them and audit the whole thing
at that point.
The first is commonly known as leak (objects are allocated but not freed).
Dangling pointers is what you will have to fight during that audit -
places where something retains kdev_t after your object had been freed.
Let me rephrase it: with your plan we will have much more complex audit
needed at the moment when you introduce freeing your objects. Reason:
it will have to involve all subsystems using kdev_t at once. That's
my problem with your plan. Sigh...
-
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 : Sat Dec 15 2001 - 21:00:19 EST