[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-smf-discuss
Subject:    Re: [smf-discuss] Code review request (6765907)
From:       Sean Wilcox <swilcox () sun ! com>
Date:       2008-11-27 4:12:50
Message-ID: 42AC12AA-8379-4733-9CB0-6CF7A7050B0F () sun ! com
[Download RAW message or body]

Tom's got a good point here, even using uu_list_insert_before(list,  
uu_list_first(list), "enabled element") I have no guarantee that this  
element will stay the first element, and that I can keep other things  
from dumping in front of it on the list.

So back to the drawing board, with a shot a Tom's idea here... I'll  
repost the webrev when complete.


On Nov 26, 2008, at 4:37 PM, Tom Whitten wrote:

> I think that it will be hard to fabricate an index for use by
> uu_list_insert().  It's pretty much an internal thing for the  
> uu_list code.
>
> I was thinking of using a technique similar to the technique that
> lscf_import_instance_pgs() uses to insure that it processes the  
> general
> property group last.  It tells its walker call back function to  
> ignore the
> general property group and report back the address of the general  
> property
> group in the call back data.  Then it processes the general property  
> group
> after walking the list, and doesn't care about the ordering of the  
> list.
>
> Perhaps you could establish a similar communication with the
> lscf_property_import() call back function.
>
> tom
>
> Sean Wilcox writes:
>> Would it be reasonable to extend internal_attach_property to take an
>> index argument that could be used to decide where a property is
>> inserted.  In most cases this would be a nop and just  
>> NODE_TO_INDEXtake what
>> uu_list_find() returns, but in the case of inserting the general/
>> enabled entry it would indicate the first entry.
>>
>>
>>
>> On Nov 26, 2008, at 3:45 PM, Tom Whitten wrote:
>>
>>> Sean Wilcox writes:
>>>>
>>>> Bug -id : http://bugs.opensolaris.org/view_bug.do?bug_id=6765907
>>>> services can be started without a running snapshot
>>>>
>>>> webrev : http://cr.opensolaris.org/~swilcox/6765907/
>>>>
>>>>
>>>> -- 
>>>> Sean Wilcox
>>>> 303.272.9711
>>>> x79711
>>>>
>>>> _______________________________________________
>>>> smf-discuss mailing list
>>>> smf-discuss@opensolaris.org
>>>
>>> Sean,
>>>
>>> You're really coming up to speed quickly on the SMF code.  I have a
>>> couple of comments:
>>>
>>> usr/src/cmd/svc/svccfg/svccfg_libscf.c:
>>> 	lines 1946-1948:
>>> 		I spent quite some time looking at the svccfg code to
>>> 		convince myself that the enabled property would be the first
>>> 		one in the list.  I found that it depends on how
>>> 		lxml_get_instance(), lxml_get_default_instance(),
>>> 		internal_attach_property() and uu_list_find() are coded.
>>>
>>> 		I would advocate for one of the following:
>>> 			a.  A more explicit mechanism for insuring that the
>>> 			    enabled property is processed last rather than
>>> 			    depending on the list order.
>>>
>>> 			b.  Comments for lxml_get_instance() and
>>> 			    lxml_get_default_instance() stating that
>>> 			    entity_pgroup_import() depends on the enabled
>>> 			    property being the first property in the list
>>> 			    of properties for the general property group.
>>>
>>> 	lines 1948, 2067:
>>> 		enable -> enabled
>>>
>>> tom
>>> _______________________________________________
>>> smf-discuss mailing list
>>> smf-discuss@opensolaris.org
>>>
>>
>> Sean Wilcox
>> x79711
>> 303.272.9711
>>
>

Sean Wilcox
x79711
303.272.9711


_______________________________________________
smf-discuss mailing list
smf-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]