* John Beck <jbeck at eng.sun.com> [2006-09-21 10:20]:
> Jan> milestone/network is not needed and will be replaced by network/profiled
> Jan> as well.
>
> Darren> I'm not sure removing milestone/network is wise. Particularly given
> Darren> that a non trivial amount of services depend on it. I think it is
> Darren> quite likely that a lot of non Sun services depend on it too.
>
> Jan> yep. I think I agree. John, any thought?
>
> It depends on how these services are ARC'd: what their interface taxonomy is.
> SMF experts: how did you set these up w/rt future changes like the one we are
> considering here?
They all have stability levels:
$ svcprop -p general/entity_stability network/inetd:default \
milestone/network:default
svc:/network/inetd:default/:properties/general/entity_stability astring
Unstable
svc:/milestone/network:default/:properties/general/entity_stability astring
Evolving
That is, the introduction of milestone/network was expected (like most
milestones) to be a useful dependency for the long term. You might
want to talk with Mike Ditto; he argued successfully that the Unstable
entities, like network/loopback, weren't appropriate for services to
depend on in general, and that a generic milestone would be a good
place to identify a boundary (around some useful subtree of network
implementation services).
You could potentially refine the semantic meaning of milestone/network
without breaking existing services--like changing what it means to
have a restart or refresh dependency on milestone/network.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
