Jason King writes:
> 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.OK. > 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. If there's an LLP-related daemon, and that daemon is controlled by SMF, the global parameters can go with that instance, right? (Just because I have multiple bridging daemons doesn't mean you need to have multiple LLP daemons, right?) Or do you have a single LLP daemon that supports multiple instances? If that's the case, then you might want to look into making each of the instances be a separate SMF instance anyway: it makes for simpler administrative control. > 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? That'd probably be fine for most. I don't think it makes sense for any administrative names for the system, though. > 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? That's what I'm currently doing. It seems to work well enough. The important thing (for my use, at least) is that the configuration storage mechanism is hidden by the library, so that the rest of the system doesn't have to know how it's stored. -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
