[Pvfs2-developers] patches: admin utilities

[Sam Lang]

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
>