ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi,
I couldn't get to sleep last night, so I was thinking about this - to
write a device driver, you need to INSMOD something into the kernel
right? Well, why did they architecture it this way, instead of having
a separate format for it, like Windows VxD or something? How does the
insmodding work? A device driver would need the functionality to
either write something TO the device, or read something FROM the
device, right? Well, how exactly is it structured, i.e. how does the
program hand the data to be written (for example) to the driver? And
when something is read, how does it get it from the driver?
The doc and howtos for driver model and loadable drivers are very high on every Google search I could concoct for your question. Here's one of the better ones. There's also the Documentation directory in the kernel repo, kernel-docs.txt might be a good place to start getting your bearings more generally.
I think you are confusing the concept of loadable modules and passing data to/from the kernel/module. insmod or modprobe are used to load the kernel module (or rmmod, to unload it). Once the module is loaded into the kernel, it can serve it's function as a device driver. The device it writes to is probably some hardware, and it uses whatever means it needs to send & receive data to/from the device.
For communicating with the userspace side, the kernel provides all of the data, as arguments to the functions in the entry table. There are different collections of standard interfaces implemented by device drivers: character & block types, principally. These define a standard set of functions and arguments which your driver must provide and register upon loading. The kernel will dispatch to your driver functions according to the needs specified when a userspace application makes system calls. When appropriate, these functions will receive or send data, which may ultimately end up transferring to/from the userspace application (or maybe just to another driver; you don't need to care, the kernel figures it out).
The link posted by jthill explains this quite well.
Well, why did they architecture it this way, instead of having
a separate format for it, like Windows VxD or something? How does the
insmodding work?
Usually, when the kernel detects a device by its PCI ID, it looks up to see what driver supports that and uses insmod to load the code for that driver. You can also specify other modules to load using /etc/modprobe.conf.
Quote:
A device driver would need the functionality to
either write something TO the device, or read something FROM the
device, right? Well, how exactly is it structured, i.e. how does the
program hand the data to be written (for example) to the driver? And
when something is read, how does it get it from the driver?
There are different methods, but the most common is for the module when it is loaded to create a device in the /dev directory. The user program opens the dev and reads or writes to it. The standard UNIX model is:
open - provides user space with a handle for the device
close - free the handle
read - transfer data from the driver to user space
write - transfer data from user space to the kernel driver
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.