[SOLVED] How to call a userspace function from kernelspace

vilhelmgray · 04-19-2013, 09:59 AM

I programming a device driver to control some hardware via I/O port outputs. In particular, my hardware takes a 16-bit value which is calculated by a rather extensive floating point algorithm (several thousand lines of code).

Naturally, I do not want to be executing floating point code within kernelspace; but I'm in a pickle since my device driver code continually polls an input byte before executing the floating point function.

floating point function:

Code:

unsigned calculate_output(char input){
    unsigned output;

    /* perform extensive floating point algorithm here to determine output */

    return output; /* top 16-bit are don't-care */
}

kernel loop:

Code:

while(inb(LIFE_PORT) & STAY_ALIVE_BIT){
    char seed = inb(SEED_PORT);

    u16 output = calculate_output(seed); /* evil floating point operations */

    u8 lobyte = output & 0xFF;
    u8 hibyte = output >> 8;

    outb(lobyte, MECHA_PORT1);
    outb(hibyte, MECHA_PORT2);
}

I suppose I'm looking for the inverse of ioctl, where the kernelspace program sends a request data command to the userspace program. Using the read and write function on a device file seems difficult since the kernel code is in a loop (would I require a kernel thread?).

I also considered using ioperm.h, but executing I/O port commands from userspace seems "dirty." Does anyone have any suggestions on how I could achieve the behavior I'm imagining (i.e. separating the floating point algorithm to userspace, while I/O interactions remain in kernelspace)?

Mara · 04-21-2013, 01:17 PM

You may try with a service thread in the userspace. The thread is blocking on a special descriptor (poll, ioctl, read, what you prefer) and when it gets out, it reads the data to process (with read() blocking it would be free), does the job and writes the data back. During this time the kernel will be blocking the original execution (on a waitqueue for example).

bsat · 04-21-2013, 11:05 PM

one possible solution could be use of a proc entry.

You could create a proc entry which the user process will read repeatedly, and on every read the kernel can fill it with the latest seed. which the user process and take and do required floating point operations and write the result back into in the same proc entry which the kernel can read it back.

sundialsvcs · 04-24-2013, 07:54 AM

I think that I would define a virtual-device because this gives you the full goodness of read, write, and ioctl.

But now, you also should write a user-land library which embodies (and conceals) all of the necessary protocol for using your facility. For instance, I might call a subroutine, passing to it the address of a callout-routine that I have written in my code. Then, I call the same or another subroutine to pass control to the library, which (alone) knows how to communicate with the kernel module.

Say, the library does this by issuing a few writes (to send data), then an ioctl to ask the kernel module to do something. The kernel does so, and returns a certain integer value that tells the library, "now, please go call the user's callout subroutine and tell me what happened." Which the user-land library obligingly does.

The key idea here is that the user-land library, which you provide, is really the one that's "running the show." It is effectively calling the kernel module as a set of magical subroutines. It has the primary responsibility for getting the work done and for concealing all of the dirty-laundry associated with getting it done.