Sowmini.Varadhan at Sun.COM writes: > So if we divide the parameters into: > 1. global parameters that apply to all modules, [...] > One proposal is to apply parameters under #1 as part of a > network/physical:default service, and those under #3 as part of a > network/ip:<link> service.
It'd have to be well before network/physical. In the current system, both network/tnctl and network/loopback run before network/physical. If we could have a network/ip:default that somehow had no dependencies (and on which all of networking was dependent), then we'd be in a better position, but I don't know if you can reasonably make one SMF instance have radically different dependencies from another instance. (Those other ip:<link> instances would have to run much later.) > Ideally we would be able to read the relevant smf settings from > ip_ddi_init() itself, but as has already been encountered in Brussels > in the past, there are no Interfaces to push smf settings into the > kernel. Using a daemon in this case is full of its own problems- > ip_ddi_init is called before any daemons are spawned (before init is > started). So at least at this time, we have to settle for the next > best approximation of associating smf-parameter settings with the > start of smf network services. The key issue I see is that the "IP service" -- whatever that may be -- should not be made available to the system until the SMF instance representing it has finished its initialization. In other words, having the IP module loaded very early in the boot process, having either SMF or non-SMF processes using it, and then having some SMF service come along much later to apply configuration and announce itself as "the" representation of the global IP service is an architectural mistake. It's a syntax error. Either we need to delay IP loading until we can actually set parameters, or we need to give up on the idea that IP itself is an SMF service. (That latter is not necessarily a bad thing -- not everything *is* reasonably represented as an SMF service, particularly kernel entities. Have you had to do "svcadm enable kmem" recently?) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> 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
