On 04/29/2012 01:54 PM, Linux Kernel Mailing List wrote: > > With both automount and systemd doing a single read() system call, and > verifying that they get *exactly* the size they expect but using > different sizes, it seemed that fixing one of them inevitably seemed to > break the other. At one point, a patch I seriously considered applying > from Michael Tokarev did a "strcmp()" to see if it was automount that > was doing the operation. Ugly, ugly. > > However, a prettier solution exists now thanks to the packetized pipe > mode. By marking the communication pipe as being packetized (by simply > setting the O_DIRECT flag), we can always just write the bigger packet > size, and if user-space does a smaller read, it will just get that > partial end result and the extra alignment padding will simply be thrown > away. > > This makes both automount and systemd happy, since they now get the size > they asked for, and the kernel side of autofs simply no longer needs to > care - it could pad out the packet arbitrarily. > > Of course, if there is some *other* user of autofs (please, please, > please tell me it ain't so - and we haven't heard of any) that tries to > read the packets with multiple writes, that other user will now be > broken - the whole point of the packetized mode is that one system call > gets exactly one packet, and you cannot read a packet in pieces. > I just looked at am-utils; am-utils *does* use autofs v5, and *will* loop back and read more data on a short read. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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