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:
[EMAIL PROTECTED] 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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
