CODEWITHSUNDEEP
clinuxlinux-kernellinux-device-driverembedded-linux
nrcrast
nrcrast

Reputation: 171

Doing work in kernel space vs user space

In my project, I have to read a bunch of data out of a Firmware FIFO constantly. I read 1 word at a time, and after 115 words are read,it's all parsed into a struct. There are two ways I can go about doing this:

1.) Implement the driver so that it gives me back 1 word at a time, and do all of the packing in user space

2.) Pass the struct to the driver, via IOCTL, and the driver does the 115 reads, then passes back the filled structure.

Number 2 appeals to me as it keeps the user space code cleaner, but I'm not sure about doing all of that work in the driver. From both a standard practice standpoint and performance standpoint, which one of these methods is better?

Upvotes: 1

Views: 250

Answers (3)

tony-p-lee
tony-p-lee

Reputation: 807

If your HW allows it and there is no hard REALTIME requirements on how fast you need to fetch those data, here is a support lazy way to do it: :-)

mmap your firmware's IO address into the user space. And just read it from your user space program.

This is good for type of situation where the "firmware" just generate 1 data per second.

Upvotes: 0

Yakk - Adam Nevraumont
Yakk - Adam Nevraumont

Reputation: 275230

A way to reduce user to kernel space communication, while keeping the complexity in user space, would be to have the user space request all 230 bytes of data at once in one call.

Then do bit and byte manipulation in user space.

Depending on how the manipulation works, it could even be done 'in-place'. You pass the struct, get it filled, then call prepare_data which does all the bit-fiddling. Go one more step and you could hide that behind a library function or even inline header file function.

Now the kernel space just provides the bytes requested, and the user space contains any and all non-trivial logic. This makes it less likely a fencepost error will take your machine down.

Upvotes: 1

nneonneo
nneonneo

Reputation: 179392

I would think this depends on whether the driver is hardware-specific or not. If the driver is expected to understand the protocol of the device (it's a device-specific driver as opposed to some generic driver), then #2 is probably your best bet because it minimizes the amount of traffic between the userspace program and the kernel. If the driver should be reasonably hardware-agnostic then #1 is what you should implement (e.g. if it were a driver for the communications protocol, like SPI/I2C as opposed to a driver for the device).

For performance, #2 is almost certainly better, because it requires 1 system call instead of 115 system calls.

Upvotes: 2

Related Questions