Tony Battersby wrote: > Stefan Richter wrote: >> I believe your kref_get_not_zero() invention is because you want to >> count two unrelated numbers in the same counter. This won't work, I'm >> afraid. >> > It does work actually, just in a way that people don't seem to like very > much. No, it doesn't work. You can track how many transactions are pending, and you can track how many sites look at memory X, but you can't track both issues in the same counter. If you only count pending transactions, you know when to deregister the device from the idr. But you don't know when it's OK to free the device's memory. If you cont only references to the memory, you know when it is OK to free it but you don't know when to deregister from the idr. > And it is not really my invention; other people have run into the > same problem and come up with the same solution. Perhaps these people did not analyze rigorously what it really is what they want to count? ... > Please, cast your votes now. I for one am not interested in what you guys do with sg. However, the proposal to change the kref API in a way which IMO undermines the whole principle of reference counting motivated me to comment in this thread, to try to understand what you want to solve, and to propose something. What is this kref_get_not_zero()? Do you want to encode object state into the reference counter? That's not the purpose of a reference count; use separate object attribute for that. The reference count says how many sites look at the object. Nothing more, nothing less. > 7) I am told to use three krefs now, using one kref to refcount another > kref. However, it may be necessary to use as many as four. ... > How much more complicated does it have to get just to make things simpler? As I said: Why count independent numbers with a single counter? Count number A with counter a. Count number B with counter b. This is easy, works 100%, and is obvious to everybody. How much simpler than that can it get? -- Stefan Richter -=====-==--= ---= -==== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
