public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Separate interrupt stack
@ 2000-07-28  2:17 Boris V. Guzhov
  2000-07-28  5:09 ` Bart Veer
  2000-07-28  5:45 ` Nick Garnett
  0 siblings, 2 replies; 3+ messages in thread
From: Boris V. Guzhov @ 2000-07-28  2:17 UTC (permalink / raw)
  To: ecos-discuss

Hi All!

There are some questions.
Is supported in eCos the separate interrupt stack for the  i386 platform?
Can I use the cyg_scheduler_(un)lock() calls in DSRs?

Thanks in advance.

Boris Guzhov,
St.Petersburg, Russia


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Separate interrupt stack
  2000-07-28  2:17 [ECOS] Separate interrupt stack Boris V. Guzhov
@ 2000-07-28  5:09 ` Bart Veer
  2000-07-28  5:45 ` Nick Garnett
  1 sibling, 0 replies; 3+ messages in thread
From: Bart Veer @ 2000-07-28  5:09 UTC (permalink / raw)
  To: borg; +Cc: ecos-discuss

>>>>> "Boris" == Boris V Guzhov <borg@int.spb.ru> writes:

    Boris> There are some questions.

    Boris> Is supported in eCos the separate interrupt stack for the
    Boris> i386 platform?

Looking at hal/i386/pc/current/src/hal_intr.c, there is some support
for a separate interrupt stack.

However, there may be problems. Looking at the configuration data I
see:

    cdl_option CYGSEM_HAL_I386_PC_STARTUP_RAM {
        ...
	requires !CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK
        ...
    }

which suggests that the separate interrupt stack is only usable when
performing a floppy bootstrap, not a RAM bootstrap. I do not know 
why using a separate interrupt stack would conflict with a RAM
bootstrap, you would have to investigate further.

    Boris> Can I use the cyg_scheduler_(un)lock() calls in DSRs?

I am not sure what you are trying to achieve here. DSRs implicitly run
with the scheduler locked, i.e. the current and any pending DSRs have
to run to completion before control returns to any threads, although
interrupts are enabled during this time.

A DSR can increment the scheduler lock further and then decrement it
again later. This happens implicitly when performing certain kernel
calls from inside a DSR, e.g. a semaphore post.

If a DSR were to perform a scheduler unlock before having done a
corresponding lock, I imagine the system would get very confused. On
the one hand there is a DSR still running and other DSR's may be
pending, on the other hand the scheduler is unlocked so application
threads are runnable. Hopefully there would be an assertion failure,
but I have not checked the code.

Bart Veer // eCos net maintainer

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Separate interrupt stack
  2000-07-28  2:17 [ECOS] Separate interrupt stack Boris V. Guzhov
  2000-07-28  5:09 ` Bart Veer
@ 2000-07-28  5:45 ` Nick Garnett
  1 sibling, 0 replies; 3+ messages in thread
From: Nick Garnett @ 2000-07-28  5:45 UTC (permalink / raw)
  To: ecos-discuss

"Boris V. Guzhov" <borg@int.spb.ru> writes:

> Hi All!
> 
> There are some questions.
> Is supported in eCos the separate interrupt stack for the  i386 platform?

Not at present. This is one of several improvements that need to be
made to the i386 HAL. We don't have time to do it, but contributions
would be welcome.


> Can I use the cyg_scheduler_(un)lock() calls in DSRs?
>

Yes. DSRs run with the scheduler locked, but you can call lock/unlock
within it if necessary (although they will have no effect). Just make
sure that you have as many unlocks as locks, and that the scheduler
always stays locked for the duration of the DSR, otherwise bad things
will happen.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-07-28  5:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-28  2:17 [ECOS] Separate interrupt stack Boris V. Guzhov
2000-07-28  5:09 ` Bart Veer
2000-07-28  5:45 ` Nick Garnett

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).