I prefer table based registration, for sure. But I actually have a
different suggestion.
The only consumer for these at present is NDD. What I'd do is abandon
attempts to support the outliers via NDD, unless there was enough users
of the "outlier" to justify promotion to a "well-known" alias or
somesuch (e.g. if all NSN drivers use a certain alternate spelling, then
you should silently convert it in the framework, with no extra effort on
the part of the driver.)
Then, the framework can just answer '?' on its own, without a
registration of private properties (though it may prove useful in some
other future project), and at least for now, we can remove this logic
from your changes altogether.
Put another way, I think anything except well-known properties (and
maybe certain "aliases") should be available via dladm only.
-- Garrett
sowmini.varadhan at sun.com wrote:
> Hi,
>
> I was just talking to Nicolas Droux and Eric Cheng,
> and they suggested that it might be more convenient
> to be able to pass a table of (prop name, perm flags)
> arguments to mac_register_prop, instead of
> registering individual props one at a time.
>
> The current signature of this function is
>
> void
> mac_register_priv_prop(mac_handle_t mh, char *name, int flags)
>
> so the suggestion is to instead change this to
>
> typedef struct mac_priv_prop_s {
> char mpp_name[DLD_LINKPROP_NAME_MAX];
> int mpp_flags;
> } mac_priv_prop_t;
>
> int mac_register_priv_prop(mac_handle_t mh,
> mac_priv_prop_t *prop_table,
> int nprop)
>
> the function will return
> 0, on no error,
> EEXIST if called more than once.
> ENOMEM if some memory allocation failed.
>
> Thus drivers could declare a static table
> of all private properties, and pass this in one
> shot to mac_register_private_prop. Another
> advantage is that this does not have locking problems
> that Garrett alluded to.
>
> The down side to this is that drivers will
> not be able to change an existing registration
> easily. Thus they have to do a monolithic
> registration of all their props.
>
> Thoughts? comments?
>
> --Sowmini
>
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/brussels-dev
>
