Ben Hutchings dixit: >ip(7) also doesn't document IP_PKTOPIONS.
Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found the correct place in the kernel for what I do. On the sending side, I use setsockopt with either IPPROTO_IP,IP_TOS or IPPROTO_IPV6,IPV6_TCLASS to set the default traffic class on outgoing packets. On the receiving side I use setsockopt with either IPPROTO_IP,IP_RECVTOS or IPPROTO_IPV6,IPV6_RECVTCLASS to set up the socket then recvmsg to get a cmsg(3) of IPPROTO_IP,IP_TOS/IPPROTO_IPV6,IPV6_TCLASS from which I read the traffic class octet. These are where I believe I found inconsistencies between code and documentation. >Those are two different APIs though: recvmsg() for datagram sockets, vs >getsockopt(... IP_PKTOPTIONS ...) for stream sockets. They obviously >ought to be consistent, but mistakes happen. OK, I’m currently looking at the datagram case only. This may change later if there’s enough time. >I see no point in changing the IPv6 behaviour: it seems to be >consistent with itself and with the standard Not really: if the kernel writes an int and userspace reads its first byte, it only works by accident on little endian, but not elsewhere. >so only risks breaking user-space that works today. Hrm. It risks breaking userspace that reads an int. But the RFC clearly says it should read the first byte, not an int. >But you should know that the highest priority for Linux API >compatibility is to avoid breaking currently working user-space. That >means that ugly and inconsistent APIs won't get fixed if it causes a >regression for the programs people actually use. If the API never >worked like it was supposed to on some architectures, that's not a >regression, and is lower priority. This is why I just put this up for discussion instead of requesting a specific change. That being said, given that the IPv6 API is *only* documented in the RFC and *not* documented in the Linux manpages… (Perhaps codesearching for IPV6_TCLASS might also help. It’s unclear how many users this has…) In the end, what I really want, is clear documentation for how I should implement the following file that it works on Linux, and ideally also other systems implementing the RFC API (FreeBSD supposedly does but needs testing): https://github.com/tarent/ECN-Bits/blob/master/linux-c/lib/ecn.c Given that there’s no documentation, trying to read the coffee grounds from the kernel source, finding it doesn’t even match the RFC (which, again, doesn’t match what itojun proposed, for some reason), does not instigate trust in the things I *think* I’ve found. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
