On Mon, Apr 30, 2012 at 1:03 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> Thinking about it some more: for v6, I wouldn't use a packetized pipe at
> all (due to the unnecessary extra buffer consumption.) Instead just put
> the message size in the header and read a large chunk, which may end up
> being more than one packet and may end up with a partial packet at the
> end. *This is okay*, because there is only one reader, and any
> additional data needed will be gotten the next time around the loop.
Yes, doing multiple streaming packets is good, but then you really do
need to design the protocol for streaming, which very much includes
having that size early in the header. And then you'd better make the
packets really have different sizes, so that you cannot possibly get
it wrong in an app that "knows" that there's one size.
However, in the case of autofs, I don't actually see multiple packets
being that common. Sure, they can happen, but it really looks like the
normal case will always be the trivial ping-pong scenario ("read one
packet, react to it, rinse and repeat").
But using a big buffer and trying to read lots at one time is valid even then.
The thing I *really* hate about the current autofs situation is how it
really does everything you can possibly do wrong. Not at all the
"let's just read as much as we can, and look at the return value to
determine number of bytes/packets", but literally "I know a-priori how
big the packet is, and I will read exactly that many bytes". That
coupled with the psueod-fixed-size packets just made it a very very
fragile thing.
Linus
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
