> The problem with using upld_buf (and therefore zero-copy in > the CF driver) is that you have no idea how long a read from > the card will really take, and what errors might happen during > the read from the card. Yes, this can take a long time. And, BTW, I don't want to use upld_buf. My idea is this: > > struct lbs_event *lbs_get_free_event(struct lbs_private > > *priv); This will take out an lbs_event from the event_free_list and return it. Taking out has to be done under spinlock, but this is very fast. Once the lbs_event is no longer in any of the two event list, we "own" it and can handle it as long as we want, without the need of an additional spinlock. Then > > void lbs_handle_event(struct lbs_private *priv, struct > > lbs_event *event); would again take the spinlock, insert the event in the event_list, and release the spinlock. Which again takes only a short time. This approach can make receiption of command responses from card zero-copy like, at least insofar the event processing is considered. > I'd argue that the CF driver should also have an internal > buffer like the SDIO and USB drivers do, and then there's still > only one copy. Yeah, but I can reduce easily to a 0-copy-scheme. I hope all of this sounds sane. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
