[Pvfs2-developers] patches: admin utilities

[Walter B. Ligon III]

Yeah, that's why I wouldn't do that if it was for more than a couple of 
instances - but it is probably fine if it just gets us out of a couple 
of situations without more changes to statecomp.  Nested SMs are cleaner 
and should work most of the time.  Slightly less efficient, but most 
likely that isn't significant.

If this happens a lot and there is a serious performance issue, then a 
RUN variant that does not declare the function is probably the least 
intrusive approach.

Walt

Sam Lang wrote:
> 
> Maybe its just laziness on my part, but wrappers annoy me.
> -sam
> 
> On Nov 29, 2007, at 8:01 AM, Walter B. Ligon III wrote:
> 
>> I like both Pete's ideas.
>>
>> The original implementation where state actions were declared 
>> "manually" allowed shared or extern actions - and that probably fits 
>> the standard C model better - it's hard to auto-generate that stuff in 
>> the general case.  But, putting all of those in there is a pain in the 
>> ass - and I think these two ideas (nested SMs and a wrapper function) 
>> are the best way to deal with this.
>>
>> Now, if we start doing it all the time, might want to re-think.
>>
>> Walt
>>
>> Sam Lang wrote:
>>> On Nov 28, 2007, at 7:41 PM, Pete Wyckoff wrote:
>>>> pcarns at wastedcycles.org wrote on Wed, 28 Nov 2007 10:24 -0800:
>>>>> Thanks for working on the update, Sam.
>>>>>
>>>>> I'm kinda stumped on that statecomp issue too.  I have a couple of 
>>>>> random
>>>>> ideas to throw out there, but I'm not really thrilled with them 
>>>>> either:
>>>>>
>>>>> - If we continue on the track of modifying the state machines, it 
>>>>> might be
>>>>> good to try to get rid of the manual function declarations for this 
>>>>> case.
>>>>> For example, maybe add two new directives, a "run_global" and
>>>>> "run_external".  The former would be used in create.sm and would be 
>>>>> like
>>>>> "run" except it wouldn't emit a static modifier on the function
>>>>> declaration.  The latter would be used in repair.sm and would be 
>>>>> like run
>>>>> except it would emit an extern modifier on the function 
>>>>> declaration.  Then
>>>>> the extra header with function declarations could be dropped from the
>>>>> patch.
>>>>>
>>>>> - This idea is kind of goofy from an organizational standpoint, but 
>>>>> if we
>>>>> didn't want to modify statecomp syntax at all, we could just put the
>>>>> repair and create state machines in the same .sm file (presumably
>>>>> create.sm).  I assume that statecomp already knows to only emit one
>>>>> function declaration once even if it is used in two different run
>>>>> directives.
>>>>>
>>>>> - I haven't looked to see how hard this would be, but maybe these 
>>>>> problems
>>>>> indicate that it would be better to use nested state machines for this
>>>>> purpose rather than reusing state functions.  I know there was a good
>>>>> reason for doing it the way the first patch did it (probably the 
>>>>> states
>>>>> need to be ordered differently enough that the nested machine 
>>>>> approach is
>>>>> a little tough), but maybe nowadays it is better to go the nested 
>>>>> route.
>>>>
>>>> Agree with this last approach.  Nested SMs would be great if they
>>>> worked out conceptually.
>>>>
>>>> Or if desperate, put shared functions elsewhere, not under control
>>>> of a state machine.  Then each SM can use its own "run my_func"
>>>> where each .sm file has
>>>>
>>>>   #include <handy-funcs.h>   /* declares func() */
>>>>
>>>>   static int my_func(SM *sm)
>>>>   {
>>>>    return func(sm);
>>>>   }
>>>>
>>>> Compiler magic should turn that into a noop.
>>>>
>>>> The various rung, run_external, run_global, etc. seem very kludgey
>>>> and icky to have to expose to people.  In a perfect world we'd have
>>>> a compiler that looks at all the SMs at the same time and gets the
>>>> declarations correct, but that's a serious pain and bad idea for
>>>> other reasons.
>>> Totally agree.  Nested SMs are the right choice here.
>>> -sam
>>>>
>>>>
>>>>        -- Pete
>>>>
>>> _______________________________________________
>>> Pvfs2-developers mailing list
>>> Pvfs2-developers at beowulf-underground.org
>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>
>> -- 
>> Dr. Walter B. Ligon III
>> Associate Professor
>> ECE Department
>> Clemson University
>> _______________________________________________
>> Pvfs2-developers mailing list
>> Pvfs2-developers at beowulf-underground.org
>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>

-- 
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University