Fixing the unfixable autofs ABI [LWN.net]

Fixing the unfixable autofs ABI

Posted May 1, 2012 7:26 UTC (Tue) by butlerm (subscriber, #13312)
In reply to: Fixing the unfixable autofs ABI by neilbrown
Parent article: Fixing the unfixable autofs ABI

Discarding data isn't so much of a problem as knowing when data has been discarded. recvmsg(2) is nice for that. You generally can't have message per read semantics for arbitrary size messages in any case because the kernel buffers must store an entire message to avoid unusual complexities. (Ask the SCTP people about the fun problems you get trying to implement a point-to-multipoint socket that supports arbitrary size messages.)

Considering that reality, all you really need is some reliable way to know whether your message has been truncated. Sockets have MSG_PEEK / MSG_TRUNC for that, so I guess the question is why wouldn't it be practical to make recvmsg(2) work on a packetized pipe so that you can do the same thing?

(Log in to post comments)

Fixing the unfixable autofs ABI

Posted May 3, 2012 19:30 UTC (Thu) by kleptog (subscriber, #1183) [Link]

Interestingly, packetised pipes have existed for a while, see SOCK_SEQPACKET (possibly only supported for AF_UNIX). They're indeed useful in cases where you want to be sure that clients don't lose sync when the packets change size. Though a well designed protocol doesn't have the problem in the first place.

I suppose changing the type of pipe to userspace would be an even greater ABI change.

Fixing the unfixable autofs ABI

Posted May 10, 2012 5:53 UTC (Thu) by kevinm (guest, #69913) [Link]

Well, yes - changing the type of file descriptor used wouldn't fix the existing binaries, which is the whole problem (in the autofs protocol, the userspace program creates the pipe with pipe(2)).

I think it was mentioned somewhere in the thread that an SOCK_SEQPACKET socket would have been a better design, but hindsight is always an exact science.