On Wed, 28 Nov 2012 10:24:28 +0000 David Woodhouse <dw...@infradead.org> wrote:
> On Wed, 2012-11-28 at 11:04 +0100, Krzysztof Mazur wrote: > > > > The ->close() routine can just abort any pending rx/tx and just wait > > for completion of currently running rx/tx code. That shouldn't take > > long. > > If it's been submitted to the hardware for DMA, it can't do that very > easily. > > And if I can't be bothered to write code to go through the entire damn > queue and inspect every packet to see if it's a data packet and check > the VCI/VPI and try to steal it, it can't be done for the software queue > either :) > > The queue ought to be short; if it isn't, then we already screwed up. > The close therefore should be quick, and it *doesn't* have to be > instant. > > If someone wants to return immediately, there's always > vcc_release_async()... > i dont think that would be quite the right way to do it. vcc_release_async() just mark's the vcc for deletion--you still need to go through and close it eventually. however, nothing would prevent you from writing a close routine that could just reschedule something periodically to check to see if the hardware finally finished closing the vcc and can be reused. the part that needs fixed for this would be marking the vcc for reuse. you would need to keep the vpi.vci marked as busy so that someone else doesnt try to reuse it while it is closing. right now, vcc_destroy_socket() always removes the vcc from the vcc list -- regardless of whether or not close fully succeeded. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
