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 at 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 at opensolaris.org >>> >> >> Sean Wilcox >> x79711 >> 303.272.9711 >> > Sean Wilcox x79711 303.272.9711
