Cathy Zhou wrote:
> Dan Groves wrote:
>> Hi,
>>
>> I updated the copy of the link management document on the UV page.  I 
>> cleaned up the introduction, added some information on SMF, and 
>> incorporated a few comments on section three.  The document is at:
>>
>> http://www.opensolaris.org/os/project/clearview/uv/link_id_management.pdf
>>
> Several minor problems:
> 
> a. I've devided phy_dev to phy_major and phy_minor.
> 
> b. mac_addr can not be stored in the form of integer, I guess it should 
> be type string.
> 
> c. /etc/aggregation.conf should be /etc/dladm/aggregation.conf, also, 
> /etc/dladm/linkprop.conf should be replaced as well.
> 

Done.

>> 2 - I didn't write about a refresh method.    I wasn't too sure what 
>> to do here.  I could have it restart devfsadmd, but I don't think that 
>> would be wise.  The reason is that the system would lose temporary 
>> mappings stored in devfsadmd which the kernel might also have stored 
>> in its data structures.  We could do this, but then we would need a 
>> way for devfsadmd to inform the kernel that it restarted, and then it 
>> needs to purge certain mappings.  Thoughts?
>>
> I would think in the case of refresh, you should use the data stored in 
> the smf repository to update the devfdadmd data accordingly, without 
> restarting devfdadmd.
> 

OK, I see how this would work.  We'd have a signal handler in devfsadmd, 
and on a refresh we'd send it a signal.  The signal handler would walk 
all the configurations, and update them.

That's good, that's what I'll do.

thanks!
Dan



Reply via email to