Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
".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.
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?
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?
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?
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.