hi, > On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi > <y...@mwd.biglobe.ne.jp> wrote: > >>>> have you checked callers and ensure that the change from EACCES to EPERM >>>> won't be a problem? >>> >>> Only ipsec_set_policy() returns EPERM instead of EACCES now, and I >>> don't think it should be a problem. >> >> "don't think"? why not? >> i asked if you checked what the callers of ipsec_set_policy do with >> the error number. do you mean "yes, of course"? >> >>> As for calling context -- I did look at the callers and mostly I just >>> moved the call inside instead of at the top. That's also why I didn't >>> remove the last one in in6.c, where is obvious that it's done before >>> splnet(), and still need to take care of it. :) >> >> i'm not sure what you mean. >> my question was about the ipsec.c change. sorry if it was not clear. >> >>> It's possible though that I've missed something. Do you see any problems? >> >> i don't know if there are problems or not. >> i'm not familiar with the code in question. >> i was just wondering about the implications of the error number change. > > Okay, I misunderstood you. I thought you were asking about the calling > context *and* the error value. > > Anyway, the error value is just returned. The caller returns it if > it's not zero. I could not find a place that checks specifically for > EACCES, or documentation that says the user should check for it. > Ioctl(4) doesn't mention it at all.
ok. > That said, where we now return EPERM is where in the future we'll > return the error value returned by kauth(9), like many many other > places in the kernel. Other parts of the networking stacks (say, > opening a raw socket) now return EPERM instead of EACCES ip(4) and ip6(4) seem to document EACCES. > -- if we're > interested in checking whether this is a problem or not we should do > so on a much larger scale, and not as a response to a specific change. i'm not sure what you mean. how can we check breakage without looking at each specific changes? YAMAMOTO Takashi > > Thanks, > > -e.