On Fri, 22 Sep 2006, Chris 'Xenon' Hanson wrote:
> Chris 'Xenon' Hanson wrote:
> > I think I can sort out the problem if I can just get a few debug printfs
> > to spit out some bits of info at certain times. But, I'm not an experienced
> > BSD kernel guy and I've been unsuccessful in doing so.
>
> Is this the wrong list to be asking this sort of stuff on? I'm racking my
> brains trying
> to figure out how to get the driver to tell me what's failing. Maybe blip out
> morse code
> in the PC speaker? I'm just not familiar with the restrictions and
> capabilities available
> to me when working inside a kernel device driver.
I'd suggest you browse the source for similar drivers and see how
they communicate.
I haven't done much kernel hacking for a *long* time, and at that
time the way to talk from the kernel was with 'printk', so called
to avoid conflict with the userland printf. However, that is now
all gone. So...
*why not put in some printf's and see what happens?* worst case,
the kernel locks up or panics. So boot your old kernel and scratch
your head.
You *know* you can do this, because you see the kernel speaking to
you whenever it boots or otherwise writes something to the console.
So just look for examples in the source code. (cd /usr/src/sys;
find . -type f | xargs -n100 grep -l print ) ought to provide
plenty of examples. (Several thousand).
Kernel is not magic code sprinkled with fairy dust; it's just our
old friend C.
Intuition tells me that the output of these kernel printf's is to
/dev/console.
Dave
--
Experience runs an expensive school, but fools will learn in no other.
-- Benjamin Franklin
