> the dladm(1m) man page asserts:
>
> ... However, link
> properties that begin with "link" are specific to a
> given link or its underlying network device and subject
> to change or removal; see the appropriate network device
> driver manpage for details.
>
> What was the motivation for this? I see that "dladm show-linkprop"
> on a laptop can produce:
>
> (0)# dladm show-linkprop
> LINK PROPERTY VALUE DEFAULT POSSIBLE
> e1000g0 zone ...
> wpi0 channel ...
> wpi0 powermode ...
> wpi0 radio ...
> wpi0 speed ...
> wpi0 zone ...
>
> and many of the wpi props are already specific to Wifi, yet don't
> begin with "link". Should we just fix the man page? As has been
> observed in various Brussels discussions, prefixing "link"
> to device-specificy props (e.g., link_flowcontrol)
> would create unnecesary visual noise for many folks, including me.
The rationale for the "link" prefix is discussed in the dladm/WiFi PSARC
materials:
However, there will be cases where a given link property is either not
generally applicable, or where we need to gain more experience before
committing to an administrative model. For these cases, we propose to
introduce a special namespace, starting with "link_"[1] that is reserved
for properties that are specific to a given link and subject to change
at any time. Accordingly, no guarantee is made to preserve behavior
across an upgrade. This distinction will be documented in dladm(1M) and
any link-specific tunables will be covered in the appropriate network
driver manpage.
[1] The actual driver name should be omitted -- e.g., "link_xyzzy",
*not* "link_bge_xyzzy".
This was originally added at the request of the Neptune development team,
but I don't think they are using it yet. I'm OK with doing something
different, but there needs to be some way to (a) indicate interface
stability and (b) provide link-specific tunables.
--
meem
