Hi,

what is the difference between the *.ko file and *.so? I understand that the first is the kernel module and the second is shared library but practically ,when installing a driver, should I use both or either one.
For example, there is penmount.ko and penmount.so To install the penmount driver do I need both? To create penmount.ko I need to recompile the kernel and then manually load it. To install penmount.so I need simply to put into the right directory and let xorg.conf load it. To make my penmount controller work do I need both actions or only one?

thnx

In laymen terms:

Kernel modules (ko) run in kernel space, user modules (so) run in user space.

Kernel spaces facilitate (or not) access to a variety of functions that user space does not.

Kernel modules are always executed in kernel space and if buggy or erroneous, can freeze the system.

User space is "protected" and a buggy module or app is less likely to crash the system.

Its a bit more complex than that, but I dont want to get into a conversation on how linux works, suffice to say you have confused me:


I am not quite sure why a pendrive.so user module is loaded by your xorg. Xorg is display only and has NOTHING to do with loading a filesystem on a pendrive.

Besides, a pendrive in linux should appear as a block device (a hard disk) and does not require a module not shipped as part of the [latest 2.6.x] kernels.

What is your system ??

I believe the penmount modules are for a touchscreen and not a mass storage device. xorg would need the so module for an input device. You would need both.

".ko" files are designed to become part of the kernel. They are literally parts of the Linux kernel itself, which the kernel can load and unload from time to time. As such, they have an extremely privileged and extremely unique role to play.

".so" files, on the other hand, are perfectly ordinary. They are "just" libraries. Ordinary, run-of-the-mill programs can use them. They're "just" collections of useful subroutines.

Don't let the similiarity of file-names mislead you.

Many device drivers are implemented in kernel space, but I believe there are some kernel-space driver interfaces which allow device-specific code to be written in user space. For example Fuse (user space filesystem drivers), and some USB drivers.

here in UK, pendrive = USB flash memory (drive).

!!

Penmount modules are indeed for touchscreen.
So do I need penmount.ko and penmount_drv.so ?
And what about egalax?
Do I need both tkusb.ko and egalax_drv.so?
Are there any 'rules' that would tell when I need both and when not?

thnx a lot

I'm just wondering if there is no README file included with your penmount files?

There is README for egalax.
In truth, three of them.
On says how to install egalax_drv.so - it is easy, just copy the file into the right dir.
Another how to build kernel module tkusb.ko
Yet another how to recompile the kernel which could be needed to build kernel module tkusb.ko

Nowhere it is said if both kernel module and .so module needed to make touchscreen work or either of them.
Does anyone know? In general, what is the rational between having two different types of modules? Isn't it easier to have one so that everyone would know what exactly to install to make it work?

thanx

I can’t speak for your touchscreen dilemma, but in general, the kernel module interfaces with hardware and provides certain hooks for userspace software to use. The X module uses some of those hooks and makes the device appear in a way useful to the rest of X (as an X input device or what have you). The kernel module must be relatively simple. This is out of want and necessity: the kernel interface should not crash the system if a bug occurs, and there are no external library interfaces provided when coding in kernel space. Any complex uses of the hooks may occur in userspace (specifically, the X module). So, in general, having just the kernel module alone would give you only the capability to use your hardware from userspace. Having just the X module alone would give you the capability to use hooks provided by the kernel (if there were any). So when you put them together, you get functioning use of your device through X.

that was a very helpful comment. Thank you.