Peter Memishian wrote:
> > 2. Description
> > --------------
> > The default values of some properties may not be known a priori
> > to dladm. For example, the default MTU of ethernet links is
> > 1500 bytes, whereas that for InfiniBand is 2044, and the value can
> > vary for tunnel links. In these cases, dladm will have to send
> > a system call to the driver to obtain the default value of the property.
> > Also, the "reset-linkprop" command will have to notify the driver
> > that the value of the property must be reset to the default value for
> > that driver.
> >
> > This feature is achieved by sending a DLDIOC{SET, GET}PROP ioctl
> > to the driver with the pr_flags set to DLD_DEFAULT. The driver
> > may then recognize the DLD_DEFAULT flag and return the default value
> > for the property (in the case of a GETPROP), or reset the property
> > to the default value (for SETPROP).
>
> This all seems reasonable for what's proposed, but I wonder how it might
> be extended to handle an additional case that's come up in another thread.
> In particular, ndd currently allows one to effectively change the default
> value, which can be handy when e.g. the set of objects that need to be
> tweaked is dynamic or large. Clearly, some thought is needed to figure
> out how to express this via dladm(1M) (a new "-d" option to set-prop?),
> but leaving that aside, I'd think that SETPROP with DLD_DEFAULT would be
> the logical way to pass that information down into the framework -- so I'm
> not sure the semantics proposed above are optimal.
>
That's a good point.
As I think about it, there are two other ways this could be done:
1) DLIOCRESETPROP or something similar, that has the same semantics as
originally proposed in this case
2) Just let the ioctl consumer handle this by doing an explicit call to
DLIOCGETPROP followed by DLIOCSETPROP with the returned value (both
using the DLD_DEFAULT flag).
I think I lean towards number 2 -- I'm not sure there is a whole lot of
merit in expressing the "reset-to-default" as a single ioctl, but maybe
the project team has reasons for wanting such behavior.
-- Garrett
