>
>
>A nit of sorts, but while we're making naming changes, could we phase out
>the "NIC" terminology in favor of "if" (for interface) throughout? For
>instance, the following is currently proposed:
>
> typedef enum nic_event {
> NE_PLUMB = 1,
> NE_UNPLUMB,
> NE_UP,
> NE_DOWN,
> NE_ADDRESS_CHANGE
> } nic_event_t;
>
>... but this terminology is inconsistent with the rest of IP, which refers
>to [physical] interfaces being plumbed/unplumbed, [physical or logical]
>interfaces being brought up/down, and [logical] interfaces changing
>addresses.
>
>It seems that this has already been done for some of the functions (e.g.,
>net_getifname() is proposed rather than net_getnicname()) but it'd be
>nice if this could be made more uniform.
>
>Alternatively, if there's a justification for the current terminology
>split, I'm all ears.
>
>
When considering what other names were available, all of them
appeared to be just as bad, if not worse: if_event_t, nif_event_t,
something_event_t. While the naming may not be in alignment with
other names, nic_event_t doesn't seem to suffer as badly. In the
case of the function calls, the "ifname" is qualified by the net_
at the front.
So, as a "nit", I accept and understand the criticism but I don't
feel that there are any other names that work as well without some
other penalty. But the comment above is just that - a nit.
Maybe not everyone likes the colour of this bike shed (that's to
be expected), but I'm happy with it and it doesn't seem to be too
offensive, all things considered.
Darren
