On Sun, May 10, 2009 at 1:12 PM, YAMAMOTO Takashi
<y...@mwd.biglobe.ne.jp> wrote:
>> 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.
Right. Do you think we need to fix the code or the documentation?
IMHO - documentation. I like being able to tell when an error comes
from kauth(9), and EPERM is a nice way to paint those.
>> -- 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?
Ideally, regression tests and documentation on what parts of the
system affect other parts and how, including documentation.
Examples:
- IPKDB doesn't compile and not included in ALL (I think we need to
use x86_{read,write}_flags() on i386, but don't take my word for it)
- errno(2) says, for EMFILE, that "[a]s released, the limit on the
number of open files per process is 64" -- is this still correct?
But I guess looking at each specific change is good enough for now. ;)
Thanks,
-e.
