[ECOS] kernel API calls allowed from cyg_user_start()?

[ECOS] kernel API calls allowed from cyg_user_start()?

[Grant Edwards]

Can somebody point me to a list of what kernel API calls are
allowed before the scheduler is started (e.g. from inside
cyg_user_start())?

Some ones that obviously work involve creating and intializing
kernel objects.

One note I found states:

  CAUTION 

  Remember that cyg_user_start() is invoked before the
  scheduler (and frequently the scheduler is invoked as the
  last step in cyg_user_start() ), so it should not use any
  kernel services that require the scheduler.

How do you know which kernel services require the scheduler?  I
assume that anything that might normally block is in that
category.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] kernel API calls allowed from cyg_user_start()?

[Gary Thomas]

On 15-Aug-2001 Grant Edwards wrote:
> 
> Can somebody point me to a list of what kernel API calls are
> allowed before the scheduler is started (e.g. from inside
> cyg_user_start())?
> 
> Some ones that obviously work involve creating and intializing
> kernel objects.
> 
> One note I found states:
> 
>   CAUTION 
> 
>   Remember that cyg_user_start() is invoked before the
>   scheduler (and frequently the scheduler is invoked as the
>   last step in cyg_user_start() ), so it should not use any
>   kernel services that require the scheduler.
> 
> How do you know which kernel services require the scheduler?  I
> assume that anything that might normally block is in that
> category.

That's what the warning is for.  You can't expect to do anything
which might cause the thread to block, because there is no scheduler
running, thus no way to get it restarted.

The safest thing to do is only use this routine to set up initial
threads and then start the kernel.  Other things like creating and
initializing kernel objects (mutexes, etc) are also safe, but not
using them [in general].

Re: [ECOS] kernel API calls allowed from cyg_user_start()?

[Jonathan Larmour]

Gary Thomas wrote:
> 
> That's what the warning is for.  You can't expect to do anything
> which might cause the thread to block, because there is no scheduler
> running, thus no way to get it restarted.
> 
> The safest thing to do is only use this routine to set up initial
> threads and then start the kernel.  Other things like creating and
> initializing kernel objects (mutexes, etc) are also safe, but not
> using them [in general].

Actually we do take some care to allow people to do things like lock/unlock
mutexes, as quite often you can't help "shared" code needing to do that. Of
course every lock must match an unlock. The kernel is deliberately set up
such that it thinks the current thread is the idle thread in order to do
that (even though it's on a different stack of course) and that the
scheduler is locked.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] kernel API calls allowed from cyg_user_start()?

[Grant Edwards]

On Wed, Aug 15, 2001 at 10:34:29PM +0100, Jonathan Larmour wrote:
> Gary Thomas wrote:
>
> > That's what the warning is for.  You can't expect to do
> > anything which might cause the thread to block, because there
> > is no scheduler running, thus no way to get it restarted.
> > 
> > The safest thing to do is only use this routine to set up
> > initial threads and then start the kernel.  Other things like
> > creating and initializing kernel objects (mutexes, etc) are
> > also safe, but not using them [in general].
> 
> Actually we do take some care to allow people to do things like
> lock/unlock mutexes, as quite often you can't help "shared"
> code needing to do that.

Yup, I remember having to deal with that sort of problem in a
kernel I wrote years and years ago.  It's the sort of thing you
never think of until you've tripped over it once.

> Of course every lock must match an unlock. The kernel is
> deliberately set up such that it thinks the current thread is
> the idle thread in order to do that

That's a clever solution.  Wish I'd thought of it.

> (even though it's on a different stack of course) and that the
> scheduler is locked.

-- 
Grant Edwards
grante@visi.com