Passing data between kernel space to User space in asynchronous way

[souvikdatta]

Hello,
I am developing a I2C CDROM client driver. The CDROM firmware supports TOC information read through a I2C command. It sends the TOC information in burst ( Interrupts a GPIO pin when it is ready ) and my CPU does a I2C read to read the TOC. When the CDROM firmware finishes sending the last data burst , it informs my CPU that it is done with the TOC, by a flag in the last data burst.

I would like to know, which is the most efficinet way I can send these TOC information to userspace?

Thanks and Regards,
Souvik

[Rubberman]

Probably using an ioctl() call from the client that will block until the data is ready, then return with data and/or status. If you don't want the client or client thread to block on the ioctl, then you probably would signal the client so it knows to send the ioctl. There may be better ways, but that should work.

[souvikdatta]

Thanks for the reply. Actually I thought of both the methods. I guess the cleaner approach is to block the user for the TOC and then once my Kthread (which does the i2c read to read the TOC from the CD device on receiving signal from GPIO ISR (which gets fired on receiving high to low edge trigger)), comes to know that it has received all the TOC content, unblocks the IOCTL entry point of the driver and sends the data back to the user.
But as the memory which is to be filled with TOC content is to be given by the user and the user is not aware of the size of TOC from before hand, in that case I guess I need to add another IOCTL ( say get TOC_count) to tell the number of records the user can expect. After this, the user can make another IOCTL request to read the TOC content, but this time with correctly allocated buffer.

As you have said, the second approach has the advantage of asynchronous read.

Can you please suggest which one is a better approach among these two from the performance perspective?

[Rubberman]

With robust multi-threading and multi-core systems the norm these days, I'd vote for the blocking method. I'd suggest having a couple of ioctls. One to wait for an event, with the kernel module returning the a status and/or amount of data to expect (don't forget that the user can also set a timer interrupt on the call), and another one to get some number of records, up to the number available. If they are low on buffer space, they may want to get them one at a time. So, maybe a third ioctl which allows the user to ask for the next available buffer as well would be appropriate. Of course, some options can be passed in the structure passed into the kernel via the ioctl() call which can determine how the call behaves. They don't have to be different commands unless it seems appropriate.

In any case, doing it this way (blocking), a multi-threaded user application can continue to process other data while one thread waits for your data. Then, it makes the data available to the other thread(s) of the program via any number of means from ring buffers to posix queues.

[souvikdatta]

Thanks Rubberman for this explanation.

Regards,
Souvik