> > 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 actually seems to define the Brussels "Private Property". > > > 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. > > I recall having this discussion before (see > http://mail.opensolaris.org/pipermail/brussels-dev/2007-June/000186.html). > Seems like the conclusion that was reached was that private properties > should be documented in the driver's 7D man page, along with the > associated interface stability.
So what keeps the driver's private property names from colliding non-private names that are later added? (That's one of the intents of the the link_ prefix. The other is making the division between private and public property names an explicit part of the administrative experience, so the admin's expectations remain appropriately set.) -- meem
