can pipes be used in a network module??
i am trying to develop a network module which interacts with a userspace program( there is lot of data so all operations cant be moved to kernel space).
callusermodhelper is an option but it invokes the userspace process again and again ( which needs a lot of setup time so it will slow down things).so,can the communucation be achieved through a pipe(if possible) with user process always in memory waiting for request from kernel and reply accordingly?
or is there any other mechanism through which this functionality can be achieved ?
thanks in advance.
One way I know that works...
I have solved a similar requirement by adding the character driver attributes to a network driver. That way I could use standard open() close() and ioctl() calls to the driver. If I needed fast access to data from the driver to user space I used mmap() to setup a shared memory region.
I don't know about setting up a pipe but you will probably find that the pipe API is not accessible in a meaningful way on the kernel side.
Hope this helps.
Adding character device attributes...
You need to lookup the various kinds of kernel modules. One is a character device, the one you are working on is a network device.
In the "probe" function of your network module, once the code has decided that the device it is looking at is the correct one, you need to allocate the character device structures and register with the kernel as a character device. The functions to do this are "alloc_chrdev_region()" and "cdev_add()".
Once you have done this the device will appear in the "/proc/devices" list and you can use the "mknod" command to create the device entry under "/dev".
Once you have the "file" entry under "/dev", you can go ahead and use the normal file commands open(), close(), ioctl() and mmap() etc... to access your module. I'm leaving out volumes here but you can find the details of these steps on the web.
unsuccessful tried with read/write and ioctl both
i tried this with read/write and ioctl function both,
with the following steps:
simple read function already provided();
simple write function provided ();
add the packet details in buffer;
/* so will control transfer to read function now , but it is not happening.
do i need to add delay in module.also userspace prog just hangs on read
call and module just ignores it*/
same is going on with ioctl fuction, is there something wrong with the approach or implementation ??
are threads neccessary...
In the book example, the read/write entry points were used to go to sleep and then wake up the various threads so in that case yes, the separate threads were necessary.
You are using the transmit I gather, to wake the single thread in your user space application. a bit weird but you probably only wrote it as a test stub.
You need something that causes your transmit code to execute, that's what I meant by "initiating".
For test purposes, always go with the simplest case. Get rid of the write() code, use your read() code which is initiated from a user space "read()" call to the device via the "/dev/xxxx" device you made when you added the character device attributes. You should use some "printk()" calls so you can see your driver's 'read()" go to sleep and also so you can see your transmit function call the wake_up_interruptible() function.
You say that your "read()" just hangs which means it's working. Your thread has been taken out of the scheduler's process queue and until the queue has a state change your process's thread will not wakeup. This will be done when your transmit function is called. That will have to be done out of the thread of the "read()" of your module.