Sebastien Roy wrote: > On Thu, 2009-09-03 at 15:58 -0700, Danek Duvall wrote: >> My only other comment (and this is more in your domain that ours) is that >> it sounds like this needs to be done earlier in boot -- won't network >> connections already be established by the time this service runs, and won't >> that make changing this configuration problematic? > > It adds a property to existing VLAN links, and this property won't be > needed unless and until an administrator creates a bridge instance using > dladm create-bridge (introduced by this project). It doesn't need to be > done early in boot since the administrator won't have the opportunity to > create a bridge until the login service has started.
It's only tangential to this discussion, but that's not quite the case. The property being added is a generic one. We noticed that the implementation lacked a standards-compliant Port VLAN Identifier (PVID) when we were doing the bridge design work, but the feature itself does in fact do something even when you don't use bridging. If you have no VLAN 1 configured on a given port, then we'll set the PVID to 1 (per the standards; making the assumed VLAN for that port be 1), and you will *not* then be able to create a VLAN 1 on the port. If you do have a VLAN 1 configured, then we'll set the PVID on that port to 0 (outside of the standard; meaning "no PVID"). Once the upgrade is complete, you can change the PVID whenever you want, and that changes the assumed VLAN for the port. Per the standards, we assume PVID 1 if we can't find it in the configuration file. The point of all that is that if (for some reason) the upgrade script isn't run, and if you happen to have a VLAN 1 configured on some port, then the VLAN will fail out at boot time, because the kernel won't allow the object to be created. The upgrade script avoids that failure mode. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
