On Tue, Mar 10, 2009 at 2:12 PM, James Carlson <[email protected]> wrote:
> Jason King writes:
>> On Tue, Mar 10, 2009 at 1:56 PM, James Carlson <[email protected]>
>> wrote:
>> > The properties in question are _not_ associated with links. They're
>> > associated with bridges.
>>
>> So essentially, there's a separate command for the non-link specific
>> properties?
>
> Not exactly. Bridges are also treated as links (because you can snoop
> on them), but as entities they have properties that are not expressed
> as linkprop values. It's given in a lot more detail in the ARC case.
>
>> >> (Is
>> >> this covered in an ARC case already?)
>> >
>> > Yep. 2008/055
>>
>> Without wanting to pour salt in some recent wounds, I'll just say I
>> hope to look at that when possible.
>
> The spec that includes all the command line usage and the SMF/SCF
> description is here:
>
> http://cr.opensolaris.org/~carlsonj/caselog/2008/055/final.materials/bridging-spec.txt
>
> The draft (not yet reviewed) design documentation that talks about the
> internals is here:
>
> http://cr.opensolaris.org/~carlsonj/caselog/2008/055/final.materials/bridging-design.pdf
Cool...
I like the idea of putting the per-link stuff in with
{get,set}-linkprop I'll dig into this in a few days to make sure there
aren't any issues with doing this.
Unfortunately, it still leaves the question of what to do about global
LLDP properties. Unless I misread the rbridge documentation you
pasted, it doesn't look like the rbridge model will map completely
(per link: yes, global: no) since there's only one daemon.
Just thinking out loud, while the standard strongly implies that they
should be able to be manipulated, they are likely to be infrequently
touched (and generally uninteresting), would it be bad from an admin
point of view to just leave them in SMF with no corresponding method
to manipulate them in dladm?
Or as a variant, just use the standard recommended defaults in the
code, and only create the properties in SMF to override values as
needed?
Perhaps in either situation if the needs later arises introduce an
interface (outside of svccfg) to deal with it?
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
