Re: More on oskit-mach booting troubles

[Roland McGrath]

> That might be what's happening. I couldn't step through the code
> farther then __down_failed (because it's an assembler function). The
> debugger ended up somewhere Letext(), but that might be a GDB quirk,
> I'll have to check that again.

You're going to need to be able to follow the assembly code to do this kind
of debugging.  Use "stepi" (aka "si") to step by instructions.
I always use "display/i $pc".

> But there's one thing I don't understand. How can you expect to wake
> up if interrupts are disabled? I noticed a couple of cli() calls
> (in ide_do_drive_command() and __down()) before osenv_sleep() got
> called, but no sti() calls. Does it make sense to do that?

You are overlooking the use of `restore_flags' and the like.  On the x86,
disabling interrupts is a bit in the processor status word, so the `cli'
and `sti' instructions are not the only ways to affect it.  Fortunately,
all the uses in the Linux drivers use the function/macro interfaces cli(),
sti(), save_flags(), restore_flags(), etc.  These are turned into oskit
glue hooks in the oskit compile of that driver code.  See
oskit/linux/src/include/asm-i386/system.h for the oskit definitions of
those.  This glue stuff all gets pretty hairy.

You don't really need to try to understand the Linux drivers or suspect
they might be wrong--we know they work.  You don't necessarily need to
understand all the oskit glue code involved--we know it works at least in
oskit example kernels, right?  I think that for now you can really assume
that the driver parts and the oskit parts are doing the right thing, and
look for where things might be getting lost between the oskit interfaces
and the oskit-mach code that's supposed to connect.

Of course, I certainly encourage you to read source and try to understand
everything.  But the Linux device drivers do not make for very easy
reading, and the oskit's universe of glue macros is pretty arcane in itself.