hey guys,

i want to know that after doing insmod module.o module is loaded into the kernel.but what happens after that.how kernel comes to know that module is inserted and when its time to run the code provided by init_module.if u can provide me code of the same,it will be highly appreciatable.

thanking in advance
krap

The module's "init" function is used to set up parameters which the driver will need later on, and to perform any necessary registration with the kernel. The registration is done by passing a structure with pointers. When a process attempts to access a device, the kernel uses that struct of pointers to invoke various functions such as "open" and "close".

For a very simple example of a driver, look at the watchdog timer code. It is a basic "character" device (of subtype "misc") and it even implements some IOCTLs.

A lot of macro magic also goes on; the kernel hackers have done a pretty good job of hiding a lot of horrible things from the device driver programmer.

no actually my point is that suppose a periodic task is defined in init_module eg

init_module()
{
pthread_create()
}

so this will create a new thread in kernel space.Now kernel should get some interrupt because of this new thread .who and how will that interrupt be generated????

If I'm not mistaken, 'pthread_create' is part of libc and not the kernel, nor are any threads created that way within the kernel. If you want to schedule periodic tasks, there are several schemes to accomplish that. For example, you can schedule a 'tasklet' for execution and if it needs to run again later, that tasklet can reschedule itself before exit.

Another point - why would that thread you created generate an interrupt? The kernel has several timers one of which, for example, is used as a "software interrupt" for UART chips which do not generate a real interrupt. So if you look at the kernel serial code you can see the details of how this is implemented. Well, I say that because I know there is such code in the serial driver - I certainly wouldn't recommend the serial driver code as the best example because it is fairly complex code with very little "obvious" about it.

The Linux Device Drivers 3 by Rubini et al might discuss the timers and "soft IRQ" - but even if it doesn't, I'm sure you can learn more about device drivers from it. The chapters are available as electronic copies from O'Reilly; if you plan to do a lot of driver development I would recommend buying a hard copy for reference. From your posts, I would say you need to read the book.

As for real interrupts, you basically request to service an interrupt and register an interrupt handler for it. Since interrupts may be 'shared', life gets a bit more complex because you have to ensure that you check that your driver is the one which needs to handle the interrupt and you must not interfere with other drivers sharing the interrupt. Just to complicate things even more, it is possible for two drivers sharing an interrupt to both have a need to service that same interrupt.

no.....see i am working on rtlinux......so since there user tasks or better rt tasks share the kernel space........so when init_module is insmod from which pthread_create is called it will create a thread or better a task which will make a new entry in rt_tasks....but my question is when all these things happen......

I mean see init_module is called..then module is loaded....now pthread_create in called....so when and how cpu will be given to perform these tasks..

RTL responds to all interrupts so that it can prioritize them. Any interrupts not processed by an RT task will be passed onto the Linux kernel for processing. Interrupts are generated by hardware; when you talk about RT it makes absolutely no sense to talk about a 'software interrupt'. So basically you're registering an interrupt handler with RTL rather than the usual Linux interrupt processor; the chief difference is that RTL is meant to give 'deterministic' latency. So basically they are exactly the same to the end user - hardware generates an interrupt, and RTL calls the interrupt handler.