On Sun, Apr 29, 2012 at 5:35 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> Which is funny/sad, because that's actually the intended way the
> interface is meant to work.
Well, the autofs packet model is actually horribly badly misdesigned
even for that: the header doesn't contain the size of the packet. It
contains the packet *type*, and from that you can then determine the
size (of course, every other program would determine it *wrongly* for
this whole x86-64 alignment reason), but that is actually a horrible
model because it assumes you know all the packet types.
(There's a "len" field in the v5 packet, but that's not the packet
length, that's the length of the name component)
And the reason nobody does that is that in practice there is only ever
one single type of packet that is possible anyway, so there's no point
in even reading the header to find the type.
So a much nicer model is one where the actual *size* of the packet is
in the header. That would have allowed for not having that fixed
maximum size of a name etc, and would have avoided the whole problem
to begin with.
Of course, the nicest model of all is to just use a packetized
interface to begin with, so that none of these issues exist. Which is
what we're now effectively moving to, unless we can find some horrible
program that makes that impossible due to it playing games and knowing
it's a "stream".
Looking at am-utils, I think we're ok so far. But maybe you know of
yet another crazy user of the autofs interfaces.
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
