[Tinyos-devel] Changing the TOS scheduler

Kevin Klues klueska at gmail.com
Tue Jan 15 20:01:13 PST 2008


To make things backwards compatible for those that don't want to
change things right away, we could add a condition that checks the ncc
version from within the .platform file and only push the
-fnesc-scheduler flag onto @opts if it is less than whatever we update
it to with this change.

Kevin

On Jan 15, 2008 6:02 PM, Kevin Klues <klueska at gmail.com> wrote:
> There is also code that I left out that will of course have to to make
> sure that all of this only happens if we are compiling for tinyos-2.x
>
> Kevin
>
>
> On Jan 15, 2008 5:34 PM, Kevin Klues <klueska at gmail.com> wrote:
> > I've modified ncc to look for a -tosscheduler flag to which the string
> > intended for the -fnesc-scheduler flag can be passed.
> >
> > If this flag isn't set,  then the value passed through to
> > -fnesc-scheduler is equal to the default, i.e.
> > -fnesc-scheduler=TinySchedulerC,TinySchedulerC.TaskBasic,TaskBasic,TaskBasic,runTask,postTask
> >
> > If it is set, then -fnesc-scheduler is set to whatever gets passed in.
> > Valid additions to the code below:
> >
> > In argument loop:
> >   elsif (/^-tosscheduler=(.*)/) {
> >     $scheduler = $1;
> >     $strip = 1;
> >   }
> >
> > Further down...
> > if (!defined $scheduler) {
> >         $scheduler = "TinySchedulerC,TinySchedulerC.TaskBasic,TaskBasic,TaskBasic,runTask,postTask";
> > }
> > unshift @new_args, "-fnesc-scheduler=$scheduler";
> >
> > If this seems reasonable and the right thing to do, I will go ahead
> > and remove the default definition of fnesc-scheduler from all the
> > .platform files and commit this change into ncc.in
> >
> > This would of course require you to update your ncc installation (i.e.
> > in tinyos-2.x/tools) to get compiling code after the change is in
> > place.
> >
> > Kevin
> >
> >
> > On Jan 14, 2008 2:30 PM, David Gay <dgay42 at gmail.com> wrote:
> > > On Jan 14, 2008 1:59 PM, Kevin Klues <klueska at gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > I sent this email a while ago, but it was just before Christmas and it
> > > > probably slipped past most people's radars.  Well I guess I got one
> > > > response, but I don't just want to change the implementation of a
> > > > component named TinySchedulerC, I want to change the name of this
> > > > component too.  Here is my question again:
> > > >
> > > > Does it make sense to move fnesc-scheduler out of .platform and into
> > > > <platform>.target like so:
> > > > NESC_SCHEDULER_FLAG ?=
> > > > -fnesc-scheduler=TinySchedulerC,TinySchedulerC.TaskBasic,TaskBasic,TaskBasic,runTask,postTask
> > > > PFLAGS += NESC_SCHEDULER_FLAG
> > > >
> > > > Currently, this flag is automatically set up with the default TinyOS
> > > > scheduler in the definition of the .platform file for each platform.
> > > > My question then is how to change the scheduler without modifying the
> > > > .platform file directly.
> > > >
> > > > I originally thought to add ' -fnesc-scheduler= '  to the PFLAGS
> > > > variable in my application Makefile, but the one defined in the
> > > > .platform file simply overrides it.
> > > >
> > > > Is there some other way to currently achieve the same result that I am
> > > > somehow not immediately seeing?
> > >
> > > I think it's a bad (very bad) idea to put flags necessary for correct
> > > compilation into the build system. Using the build system should not
> > > be a requirement.
> > >
> > > If you want to be able to change the scheduler component name, add an
> > > option to ncc and use that in the -fnesc-scheduler= options.
> > >
> > > FWIW, the -fnesc-scheduler= option should probably move into ncc.in,
> > > as it's the same on all 2.x platforms (I think it was in .platform as
> > > it was an easy way to get the 1.x/2.x difference in there, but there's
> > > already a 1.x vs 2.x test in ncc.in at the beginning where it
> > > differentiates between $TOSDIR/platform (1.x) and $TOSDIR/platforms
> > > (2.x))
> > >
> > > David
> > >
> > >
> > > David
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
>
>
>
> --
> ~Kevin
>



-- 
~Kevin


More information about the Tinyos-devel mailing list