refactor(virtqueue): Don't swallow errors on incorrect pop order

[Gelbpunkt]

Currently, callers have no way to know whether pop_front_* methods returning None means that no data was received yet or whether they were trying to pop in the wrong order, e.g. trying to read a packet payload before the header. This would keep repeating infinitely if a driver was reading in the wrong order.

This is always an irrecoverable programming mistake, so let's panic.

[mkroening]

I think returning a Result<Box<T>, PopError> would be preferable to having this extra option inside the result. Similar to io::Error::WouldBlock, we could add an appropriate variant to our error for signaling no data is available.

We should think about if it is useful for the driver to know there was an incorrect pop order? Is there any scenario in which this is not a programming error but something that can be usefully recovered from? If not, we should probably just stick to panicking.

[Gelbpunkt]

I think returning a Result<Box<T>, PopError> would be preferable to having this extra option inside the result. Similar to io::Error::WouldBlock, we could add an appropriate variant to our error for signaling no data is available.

We should think about if it is useful for the driver to know there was an incorrect pop order? Is there any scenario in which this is not a programming error but something that can be usefully recovered from? If not, we should probably just stick to panicking.

In pretty much any case I can think of, this would be a programming error that cannot be recovered from. I initially wanted to panic here, but @cagatay-y was in favor of returning a Result. IMO either way is fine, the question really just is where we want to panic - in the drivers or in the virtqueue code.

[Gelbpunkt]

Changed to a panic.