[Pvfs2-developers] patches: admin utilities

[Walter B. Ligon III]

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