HI John,
A simple way to do this is to use the "module_init" macro
static int __init my_init_stuff(void)
{
return 0;
}
module_init(my_init_stuff);
You can see all the init calls as they happen
using the initcall_debug command line option
root=/dev/mtdblock0 rw initcall_debug=1 ...
Or by setting the variable ( just as a test)
initcall_debug to 1 in
init/main.c
Regards
Phil Wilshire
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote on 2007-10-15 06:03:59 PM:
On Monday 15 October 2007, [EMAIL PROTECTED] wrote:
Yes I have puzzled through this and read a lot of material and code
but
have not quite found this answer.
you're wondering how the initcall mechanism works and how to use it
yourself ?
-mike
Mike
Absolutely!
I see most of how the initcall mechanism works. I have read through
Christopher Hallinan's book, "Embedded Linux Primer" and followed the init
thread
through ~/init/main.c and ~/include/init.h for ARM (he doesn't show a full
working example, I guess you buy Montevista for that.)but am having no
luck having the linker pick up the __setup_parameter macro by itself.
as in "static init __init bjcs_leds()".
I guess I need to rule out "is there a linker thing to do extra" seemingly
not.
Do I have to have to have the module in a favorite place?
Did I screw up my syntax? (Highest probability!)
In your code on blackfin is there a good example?
Thanks John
(P.S. I have presented as 20/20 hindsight I should have taken your
course.)
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev