Quoth Zhenghui Xie on Tue, Aug 22, 2006 at 02:23:41PM -0700: > >>I. property groups: > >> All property groups and the properties in each group belong to the NWAM > >> service. The NWAM service has 4 types of property groups: > >> 1. a set of LLP groups: each LLP in NWAM is translated to a LLP property > >> group in SMF. The name of the LLP is used as the name of > >> corresponding SMF > >> property group. This group includes the following information:[3] > >> 1). datalink information. > >> - the name of the datalink (e.g. bge0) > >> - type of the datalink (e.g. ether, 802.11g) > > > >Is this necessary? Can't you determine the type of the datalink from > >the system, once you know its name? If this property is wrong, what > >would you do? > > It is necessary at least for wireless links. As I know, we cannot tell > the type from the name of a wireless driver. And the type of the > wireless driver needs to match the wireless network the system is trying > to connect.
Do you mean that wireless links can connect to multiple types of networks, and must be instructed which one to connect to? That would be fine, but it should be described as "type of [wireless] network" rather than "type of datalink". > >> 2). IPv4 information. > >> - how to get IPv4 address, DHCP or static or something else > >> - the address(es) on this link > > > >This is runtime state, right? If so, then do you really need to record > >it in the repository? If so, it should be a nonpersisten property. > >Which right now means it needs to be in a separate property group. > > I am not sure that IP addresses are runtime only. For static IP > addresses, their values will be consistent across reboots. Ok. Then please change the description to "static addresses for the link (if static addressing is chosen)". > as of non-persistent vs persistent, I think I need a little more > education. How do we store some property as non-persistent, and some > other as persistent? By persistent, I mean those that won't change > across reboots, non-persistent means those that may (or may not) change > across reboots. When you create a property group in the repository, you can set the SCF_PG_FLAG_NONPERSISTENT flag. When the system is rebooted, all such property groups will be deleted. > And are non-persistent properties associated with a certain service? No. They may be associated with anything that an ordinary property group may be associated with. > >> - canonical interface name, e.g., jurassic-68.sfbay.sun.com > > > >Is this static configuration or runtime data? > > same as the address, it can be static and can be runtime too. I think I'd advise that you separate the two. Have a persistent place for static configuration, and have a nonpersistent place for the current state of the system. (Though I wonder if there are networking interfaces for the latter that would be better.) > >> 3. A set of network groups: one property group per network. The name of > >> the network is used as the name of the property group. Note that you only have on property group namespace. If you want to be able to have separate LLP's & network groups with the same name, then you'll have to add prefixes to each. > >>III. A table of NWAM properties: ... > >>(only one ULP property group on the system) > > > >I thought the policy of which ULP to choose would be in each ULP's > >property group, too. So either NWAM will look in the profile for each > >ULP, or you need to have all of the ULP property groups available. > > I don't disagree on this. > > I can imagine that both (have the policy in each ULP and have separate > policy file) should work. I tend to prefer having a separate policy > file, in other words having some policy property groups in SMF > repository, for two reasons: > 1. because we have a centralized place for policies, it will be each to > make changes > 2. we only need to have one single ULP in the repository. different > network environment will have different values for this ULP. but the > properties of the ULP are the same. Unless the ULP selection policy algorithm prevents it, the information should be stored in each ULP. Keeping them separate introduces synchronization problems (e.g., if you delete a ULP, then you have dangling policy information). David
