[brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008]

[Peter Memishian]

 > I still feel that this merits its own case: the ioctl itself could,
 > in theory, be issued by any app.

How so?  The DLD ioctl API will never be public.  We may (on the other
hand) commit the libdladm API.

 > Moreover, the naming convention here is not clear to me: will DLD*PROP
 > ioctls pass down a dld_ioc_prop_t structure that has pr_num that starts
 > with "MAC"? In this model, will dld_ioc_prop_t structures live in
 > dld.h, and the MAC* definitions in mac.h?   There's a lot of parameters
 > here, and I am not comfortable mixing those parameters into this
 > case. We could address the naming conventions for the DLD*prop in a
 > separate case. Is that acceptable?

It's acceptable to me, but I'm just a PSARC licensee, so what I think
doesn't really matter ;-)

 > > I presume the same would be true if it attempted to register a framework
 > > link property name like "autopush"?  If so, that seems dangerous since
 > > namespace collisions that may be introduced over time (e.g., as we grow
 > 
 > This is not intended to be a general purpose mechanism for property
 > management at all, and is really only intended for the "legacy" ndd
 > props.

Hmm, I think I'm thrown off by the name; "mac_register_priv_prop()" seems
to be generic to all driver-private properties.

 > /sbin/dladm itself will filter out private properties that do not begin
 > with "_". In the example that you cite, if "autopush" is registered,
 > then the (driver-private) implementation would never be accessible via
 > dladm becuase (1) it does not start with "_" (2) the defined precedence
 > is for the public property.

Now I'm confused.  I thought the goal was backward-compatibility with any
existing non-canonical ndd parameters, but I don't quite see how that
compatibility is provided given the "_" constraint above.  Is there a
mapping going on that isn't described in the original proposal?

 > > the set of framework-native link properties) will go unreported, which may
 > > lead to unpredictable behavior.
 > 
 > If the concern is around the lack of error reporting, the synopsis
 > of mac_register_priv_prop can be changed to return an int, with 0
 > return status indicating success, and EEXIST indicating that the
 > registered name is a duplicate. 

That is one of the concerns, but I'm really trying to sleuth out the
various edge cases.

-- 
meem