On Tue, Jul 21, 2015 at 2:40 AM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 07/21/2015 12:24 AM, Alexei Starovoitov wrote: >> >> On 7/20/15 3:15 PM, Alex Gartrell wrote: >>> >>> The ship has probably sailed on this one, but it seems like ENOSPC >>> makes more sense than E2BIG. Any chance of changing it so that poor >>> ebpf library maintainers in the future don't have to wonder how their >>> argument list got too big? >> >> >> sorry, too late. >> It's in tests and even document in bpf manpage: >> "E2BIG - indicates that the number of elements in the map reached the >> max_entries limit specified at map creation time." >> I read E2BIG as "too big" and not as "argument list is too long" :) > > > If some libraries do an strerror(3) on errno then it certainly sounds > a bit weird, "no space left on device" perhaps also a bit misleading. > The bpf(2) manpage was actually submitted/discussed longer time ago, > but I still didn't see it in Michael's tree yet, will ping him again.
I was just being whiny :) The options really are ENOMEM -- really should mean allocation failed E2BIG -- really should mean argument list too big ENOSPC -- really should mean that a physical device is full I suppose there's also EDQUOT -- Disk Quota Exceeded And if you're really stretching EXFULL - Exchange Full but I've never seen either of the last two in my life. So clearly this is all very subjective and people who complain about it on mailing lists (me) are the worst. The only complaint I'd have though is E2BIG actually does mean that your bpf_attr argument is too big as well, so that part confused me for a couple of minutes. But, the EINVAL errno has similarly been abused to death so I don't think it's that big of a deal. /bikeshedding -- Alex Gartrell <agartr...@fb.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
