On (09/05/07 17:55), Artem Kachitchkine wrote:
>
> Here are my notes on the problem so far. Nothing incredibly new, just an
> attempt to systematize what we already know.
>
> Problem:
>
> Typically, link properties are "pushed" into drivers via ioctl, which is
> what dladm {init,set}-linkprop do. Sometimes, however, drivers need to
> actively request ("pull") properties.
>
> Constraints:
>
> C1. There are no kernel APIs to retrieve link properties from the
> backing store (we can read linkprop.conf today, but that will break when
> the store moves to SMF) - which means that before driver requests can be
> satisfied, properties must be pushed into the kernel by some userland
> agent. There is no way around that.
>
> C2. Drivers may need properties as early as attach(9E).
>
> So any solution revolves around caching properties in the kernel, in one
> form or another.
There is a third constraint:
C3. diskless boot introduces its own constraints. In a perfect world,
we do not want dependancy on daemons because, in the case of
diskless boot, init is started much later than driver's attach, so
if we have a dependancy on daemons, the store property information
will not be available.
The workaround that we (and Clearview) have, for this case,
is to reset (stop/detach, attach/start) drivers after
init comes up.
> 1. Promiscuous caching
>
> Populate kernel cache with all properties at boot time and refresh it
> every time libdladm updates the backing store.
>
> Pros:
> - Simple
>
> Cons:
> - Wastes kernel memory. (What if we use pageable memory via segkp?
> Network drivers should be able to tolerate page faults if they don't
> access properties from interrupt context.)
>
>
> 2. Selective caching
>
> Constraint C2 makes selective caching hard, because device configuration
> is kernel-driven and nothing in userland can predict when a particular
> device is attached in order to pre-populate cache for that device. (E.g.
> hooking into 'ifconfig plumb' is not an option, because so many other
> system activities can trigger network driver load-and-attach, like an
> innocent 'ls /dev/bge*').
>
> 2.1. In our current Brussels prototype, drivers explicitly request the
> mac layer to populate property cache for {macname,instance}. It can be
> done at any point, including attach(9E). The mac layer performs a door
> call to the userland daemon, which pushes the corresponding properties
> into the kernel before returning the door call. Cached properties are
> removed upon mac_unregister().
>
> Pros:
> - Saves kernel memory
> - No impact on drivers that don't pull properties
>
> Cons:
> - Daemon, kernel->user dependency, door file in /etc: lots of
> redundant cruft to solve a small problem.
Also the workarounds needed for C3.
> 2.2. DACF pre-attach
>
> DACF only provides post-attach, but it was proposed that pre-attach
> could be added, and used to load link properties before instance
> attach(9E) is invoked. DACF is a purely kernel framework, with no ties
> to userland.
>
> Cons:
> - Assumes macname == driver name (2.1 allows them to be different)
> - Loading properties into the kernel pre-attach does not provide any
> apparent benefits compared to loading them during attach. Why bother
> with extending DACF?
Also, the core problem still remains, namely, we still have to find
a way to pull the properties from the saved repository into the kernel.
--Sowmini
