kernel driver vs userspace program
Hi guys, I'm building an electrical device which will be controlled by computer. It will have an embedded microcontroller and will use USB to communicate with the PC. I believe this calls automatically for a device driver, correct? And for using the machine from the PC, interacting with it, that calls for a userspace program, correct? I mean, doing things differently, such as all in userspace or all in-kernel, would be bad form, right? My question is in case the machine is used in an industrial context where there is really only one usage and one kind of interaction that follows a pre-determined procedure (therefore totally automated). This could give extremely high priority of execution, I guess. Similar to a factory robot controlled by a computer. Would it make more sense to have everything in kernel space, while the userspace (if any) would only serve the purpose of reporting? To be a lot more general, I find it simple at first glance to understand what goes where between kernel and user space. But despite this, I often find myself in a gray zone (to my perspective) or I find myself trying to "fit" something I feel is the wrong place. I would need to read more on the philosophy of these different processing spaces, about the design behind them and the usage this philosophy prescribes. Anyone know where I could read about this in greater detail? Thanks, Simon
On Thu, 31 Jan 2013 13:38:07 -0500, Simon said:
Hi guys, I'm building an electrical device which will be controlled by computer. It will have an embedded microcontroller and will use USB to communicate with the PC. I believe this calls automatically for a device driver, correct? And for using the machine from the PC, interacting with it, that calls for a userspace program, correct? I mean, doing things differently, such as all in userspace or all in-kernel, would be bad form, right?
My *first* reaction would be "do it almost all in userspace and use libusb to talk to the device from userspace". Unless there's weird wonkyness or quirks that have to be handled by a kernel module.
My question is in case the machine is used in an industrial context where there is really only one usage and one kind of interaction that follows a pre-determined procedure (therefore totally automated).
There's no reason that an embedded system can't fire up a /sbin/init that isn't a standard 'init' but is a program to do the process control needed - in fact, most no-MMU and many embedded systems do that.
This could give extremely high priority of execution, I guess.
First, see if you're able to meet the timing constraints from a regular userspace before worrying about going the RT and/or kernel route. A lot of embedded controllers are amazingly fast and may not need any extra assistance to make the timing issues.
Similar to a factory robot controlled by a computer. Would it make more sense to have everything in kernel space, while the userspace (if any) would only serve the purpose of reporting?
Especially in the embedded world, there really isn't one right answer. You'll have to do some trial-and-error to see what balance of userspace versus kernel is the proper fit for your application. But in general, you want to try to keep it in userspace (where things are more protected in case of a stray pointer, etc) if at all possible.
Thanks for the reply! I have to say because I'm so much interested in doing some kernel programming, that I didn't pay too much attention to your suggestions, although I did find them very good. [...good information stripped...]
versus kernel is the proper fit for your application. But in general, you want to try to keep it in userspace (where things are more protected in case of a stray pointer, etc) if at all possible.
This last suggestion, however, was a truly convincing point on what should or should not be in kernel. I realize now that the segmentation faults I see once in a while, when I do something silly in my usual programs, will turn into complete denial of service requiring physical access to the machine for a reboot. I now see your other arguments as much more sensible, even for someone who's "really interested in doing some kernel programming"! I think my approach will be to make a first proof of concept completely in userspace, then move some parts of that program into kernel space. This also allows performance comparison and correct optimization of code (as opposed to the premature type). This also convinces me to use FUSE for my filesystem trials. My personal preference is to avoid FUSE, but I prefer much more to avoid rebooting often! ;) Thank you so much Valdis! Simon
participants (2)
-
Simon -
Valdis.Kletnieks＠vt.edu