[ECOS] HAL Diagnostic Output Question

Jeffrey R. Szczepanski jrs@inscitek.com
Mon Jan 26 18:54:00 GMT 2004


Anybody else have any additional insight on this one?

...In any case, thanks to Andrew for taking a second crack at my question.

Thanks in advance,
Jeff

> On Mon, Jan 26, 2004 at 10:34:56AM -0500, Jeffrey R. Szczepanski wrote:
> > Andrew,
> >
> > Thanks for your reply. What you describe makes sense, however, I have
not
> > actually put my eyes on the code that makes this work as you say. So
please
> > indulge me a little further.
> >
> > I understand how the polled I/O part works in the HAL...in fact I wrote
my
> > own version for this particular platform and I know that I don't disable
> > interrupts there. Of cource, the other drivers I have looked at don't
appear
> > to disable interrupts themselves either in these I/O routines, so I
think I
> > am consistent with other implementations.
> >
> > I have examined diag_printf() functionality itself and have not noticed
a
> > explicit mechanism to disable interrupts there either. But maybe I
missed
> > some #define that makes that happen. However, it doesn't seem logical to
do
> > that there, because the I/O could be mapped to other putc mechanisms
other
> > than HAL I/O that would want interrupts enabled.
> >
> > Now, I would certainly believe interrupts get disabled through the
virtual
> > vectors support area, with all the macro defines going on there. However
> > best I can tell, I don't see interrupts get disabled. There is an
> > ENTER_MONITOR macro that would disable interrupts, but it only appears
to do
> > that for network builds - like when Ethernet is used for HAL I/O....but
not
> > when serial port is used raw.
> >
> > It seems likely that is the area I missed something in. Perhaps you can
give
> > me a code pointer to what I am missing.
>
> Its a long time since i went dig in that area of code, so i cannot
> easily point to a line where they are disabled/enabled. Things have
> also changed as well since then. It may actually no longer be true!
>
> It could be the scheduler is locked. That would allow an interrupt to
> happen but a context switch would not be allowed. So that would also
> fit the pattern you see, ie other threads cannot run.
>
> Sorry i cannot be more helpful.
>
>       Andrew
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss



More information about the Ecos-discuss mailing list