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. -Phil > > Hi Phil, > > First off, thanks for the patches. They'll be useful for debugging > stuff, and setting up failover deployments. I committed the first two. > > I've attached an updated patch for the validate repair patch with > some changes to get stuff working with MAIN. The conflicts were with > the new state machine code. You're calling the create state actions > from multiple state machines, which we've never done before. > > I had added some code to statecomp to auto-generate the declarations > for state actions based on the "run <action>" directive it finds in > the state machines, but the declarations were static functions, which > doesn't work with your patch, since the state actions in that case > have to be public. The patch adds a 'rung' directive to the state > machine code, which is pretty much the same as run, but it just skips > the function declaration (rung == run global). It feels like a > kludge at this point -- I don't want to add another state machine > directive if I can avoid it, but I can't think of a better way. > > -sam > _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
