Michael S. Tsirkin wrote:
On Tue, Jun 02, 2009 at 01:41:05PM -0400, Gregory Haskins wrote:
And having close not clean up the state unless you do an ioctl first is
very messy IMO - I don't think you'll find any such examples in kernel.
I agree, and that is why I am advocating this POLLHUP solution. It was
only this other way to begin with because the technology didn't exist
until Davide showed me the light.
Problem with your request is that I already looked into what is
essentially a bi-directional reference problem (for a different reason)
when I started the POLLHUP series. Its messy to do this in a way that
doesn't negatively impact the fast path (introducing locking, etc) or
make my head explode making sure it doesn't race. Afaict, we would need
to solve this problem to do what you are proposing (patches welcome).
If this hybrid decoupled-deassign + unified-close is indeed an important
feature set, I suggest that we still consider this POLLHUP series for
inclusion, and then someone can re-introduce DEASSIGN support in the
future as a CAP bit extension. That way we at least get the desirable
close() properties that we both seem in favor of, and get this advanced
use case when we need it (and can figure out the locking design).
FWIW, I took a look and yes, it is non-trivial.
I concur, we can always add the deassign ioctl later.
I agree that deassign is needed for reasons of symmetry, and that it can
be added later.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
