[Pvfs2-developers] patches: admin utilities

[Sam Lang]

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
>