This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: kernel API calls allowed from cyg_user_start()?
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Subject: Re: [ECOS] kernel API calls allowed from cyg_user_start()?
- From: Grant Edwards <grante at visi dot com>
- Date: Wed, 15 Aug 2001 16:40:52 -0500
- Cc: Gary Thomas <gthomas at redhat dot com>, ecos-discuss at sources dot redhat dot com
- References: <XFMail.20010815143238.gthomas@redhat.com> <3B7AEAE5.32EA8665@redhat.com>
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