I've done enough work with them to know they are a severe challenge. I've occasionally had to alter some predefined values. I wrote a linux driver that prints 'hello world' to dmesg. I couldn't write a real driver yet.

But I know enough to tell you that windmills device drivers don't work that way. The kernel isn't going to reach into userspace, rip one function out of your userspace program, and run it raw because you don't get the same kind of stack; you don't get an ordinary heap; you don't get anything from libc; you don't get the same kind of files -- what does stderr even mean when you have no descriptor table? -- you don't get easy system calls like read() and write(); you don't even get easy, direct access to large amounts of available memory, and what memory there is is laid out in an alien way. The ease of all these things in userspace is a convincing illusion created by the kernel, more or less, and the way to use them is to be in userspace. Ordinary code can't run in kernel space any more than you could breathe in a vacuum.

Nearly all communication with the kernel is done through files and system calls instead. Your device driver can create a device file under /dev/ tied to your own kernel functions. someone opens it and your driver's read handler gets called, someone reads it and your device's read-handler gets called, etc. On boot, something in userspace could read from the ROM device and dump it into your special firmware-loading device file, and you'd be done.