Re: CVS commit: src/sys/netinet6

[Elad Efrat <elad%NetBSD.org@localhost>]

On Sun, May 10, 2009 at 1:12 PM, YAMAMOTO Takashi
<yamt%mwd.biglobe.ne.jp@localhost> 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.