>
> I am aware of the model you are mentioning, that each link is modeled as an
> service instance, and I fully agree that it is the way to go. But the
> Clearview project is not the project to make that model change, and in that
> respective, we are not making things any better or any worse.
>
> Note that the Clearview project uses SMF strictly for the data-link
> configuration persistence. We choose to use SMF mainly because we'd like to
> not introduce any more private /etc/*.conf configuration files, and the SMF
> implementation can be easily leveraged to be an alternate approach to
> satisfy our needs.
>
> Further, the needs for the dladmd daemon is independent from the use of SMF
> repository. As is discussed in last mail, the dladmd daemon is needed for
> two reasons: management of the link name, linkid namespace, and data
> persistence initiated from the kernel. But we could choose to use the
> private configuration file instead of the SMF repository.
>
> I am afraid that there might be something that I don't understand from your
> mail. I don't see how the change of the SMF model could remove the needs for
> the daemon, as you seem to imply. Can you please elaborate? Or if you have
> other suggestion, please also let us know, and we'd like to consider.
>
Here's the problem: you're in effect proposing that you persist the set of
datalinks configured by the administrator inside the dladmd service as one
big blob of property groups. In the world we agree we need to get to,
the datalinks would be represented by separate instances. This means
the persistence aspect would have to be moved to those instances, because
otherwise one cannot do a sane transaction on SMF to change a datalink.
That is, you can't spread the state of an abstraction across multiple
instances, because otherwise you can't perform a transactional refresh
of a single instance to effect a change to the system -- you would have
to do multiple steps to multiple instances to change one object, and that
would lead to possible partial inconsistent states if you die in between.
So in the model we want to get to, we would have to rip out all of the
properties in SMF you are proposing to define now and totally rethink the
persistence aspect. (And that has major downstream implications: consider
the impact to things like NWAM and also say what an Installer might want to
do to help people set up networking) This really needs to be solved now, and
frankly I don't think there is any reason it can't be solved now -- it isn't
some vast amount of work beyond what you're already proposing, it's just a
matter of working out the schema a bit more, and frankly it might simplify
things considerably.
I'm more than happy to sit down and work this out with you, although I
suspect it would be faster to set up a meeting in person or phone.
But here is the rough idea of what I would suggest:
Persistent data links should be instances, along the lines of
network/datalink:bge0. They can all share a single method script which
takes the per-instance properties and calls dladm with the -t flag to
instantiate the underlying kernel object. Creating a persistent data link
creates a new instance, sets up the properties as appropriate, and enables it.
SMF enforces the namespace for persistent things. The kernel enforces the
namespace for the set of abstractions that actually exist. If you disable
a persistent datalink, create a temporary one of the same name outside of
the world of SMF, and then enable the persistent instance through SMF,
then that instance should simply fail dladm -t with EEXIST or whatever and
enter the maintenance state. (This is administrator error).
This entirely handles the case of temporary objects (they work just like
they do today) and creating and deleting persistent objects. It also handles
system boot, because SMF starts everything in dependency order and then the
method script just executes dladm -t in the right order to poke the kernel.
The only case that remains is the upcall case, which if I'm following your
docs correctly is where I have a persistent configuration, but it isn't
attached yet, say because my Wifi gizmo is off, or I DR'd the thing out and
now I'm DR'ing it back in again. One could indeed trivially solve that with
a daemon, but actually as far as I can tell it could be solved by a shell
script invoked by RCM or SysEvent as they exist today -- since you've
persisted the device instance name (and you still would in my model),
you just do this assuming $instance is the thing you just attached:
for fmri in `svcs -Ho fmri network/datalink:*`; do
if [[ `svcprop -p group/instance $fmri` = $instance ]]; then
svcadm enable $fmri
break
fi
done
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
