Subject:
|
Re: Ideas for 0.2.5 (was: Re: Possible bug with bss allocation)
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 24 Jul 2000 01:10:23 GMT
|
Viewed:
|
2503 times
|
| |
|
|
This will be my last post for a few hours- I have real work to do :)
On Mon, 24 Jul 2000, Eddie C. Dost wrote:
> > Paolo and others:
> > Eddie and I have talked about this, and we both agree that this is a big
> > change- so I think we are aiming for this for 0.2.5. Since it has already
> > been seven months since 0.2.3, I think we'll aim for getting 0.2.4 out the
> > door as soon as we can, and then we all have some really good ideas for
> > 0.2.5- Eddie's work would be the first step.
>
> While we are at it, I have two other major changes in mind:
>
> - Implement timers. A timer would install a callback function with a
> private to the caller void * argument. This callback function is called
> at the timers expiration time. This would significantly cleanup systime.c
> as all modules could install their own timers. No more hooks inside
> the timer interrupt with all the #ifdef CONF_XXX around them.
>
> User programs could use timers. This would help a lot I believe.
Generally, user programs have it pretty simple for this already (which is
why I had thought of this some time ago, and then dismissed it.) I had
never considered the implications for the kernel, though. You are right
that it would significantly clean up systime.c. I'm a little worried about
overhead- isn't it much more efficient to do it directly within the timer
loop? Otherwise, we are constantly polling some type of timer queue (I'd
assume) to see what timers have expired and then execute them. This seems
like quite a bit of overhead, at least intuitively.
> - Implement event queues. Anyone waiting for an event can add a callback
> to the event in question (this will put the thread to sleep).
> Events are triggered by timers or by the sensor interrupt for example.
> Triggering an event would wake up all threads sleeping on the event queue.
>
> Currently events are implemented by constantly polling the required
> value from the scheduler during each time tick. How wasteful!
> I believe this could reduce power consumption by another 1 or 2 mA
> (see my mail about sensor reading for more reduction).
As with the sensor issues, I worry a little bit about reduced flexibility.
But that is a pretty minor issue, and the added ability to use wait queues
in user space would definitely be nice.
> Both changes can be made with very little code added, and will definitely
> result to reduced code at other places, so overall code size should not
> be a great problem here.
These both sound like pretty good ideas. I'm a little concerned about
managing patches this large and complex, but I think we can make it work
out without too much trouble (especially since I'll stop doing "real work"
out of CVS and can depend on 0.2.4).
One other thing: I've updated the TODO list in CVS, as a start on 0.2.5
and beyond. I know I've forgotten at least one thing, but I'll think of it
later, I'm sure. If others want to read it and throw in their two cents,
this thread is a perfect place to do it...
Luis
-----------------------------------------------------------------------
"Summertime... and the living is easy...
fish are jumping and the cotton is high...
So hush, little baby, baby don't you cry."
-Ella
-----------------------------------------------------------------------
|
|
Message is in Reply To:
8 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
