Related
Suppose I build a module in kernel 2.6.32-431, but I load it successfully in kernel 2.6.32-432. Can this module work properly? Or is it harm to system?
With such a little difference between kernel versions (2.6.32-431 vs 2.6.32-432) and by passing checksum check (see e.g. this answer about checksum in Linux kernel modules), your module will very likely operate correctly.
Of course, no one can be sure about correctness.
The version of your kernel is 2.6.32.
The number you see after the dash (-432) is an iteration of patchsets applied by your distribution's developers. Most of those changes likely are security patches.
Moreover, 2.6.32 kernel is an LTS release, which normally doesn't accept anything, but security updates and fixes for severe issues.
So, you should not worry that module compiled with 2.6.32-431 kernel sources won't work on 2.6.32-432 kernel.
What you should really worry about is that 2.6.32 kernel is not supported since February 2016.
As long as your changes complied successfully under the module build in your new kernel version, it should not be a problem. It should work normally 99%.
Do
Linux system calls
Linux API
depend on
Linux distributions (e.g. Debian, Fedora, Ubuntu, Arch, Gentoo, ...), and/or
Linux kernel?
To answer your question about Linux System calls, you need to read man syscalls.
So yes, with different distributions, Linux kernel will change, hence the available system calls.
What do you mean by Linux API?
Linux Kernel's internal API
or the C ABI
Answer depends on the fact that is it a POSIX compliant call and if you are using a POSIX compliant system.
If your are using a POSIX call them most the system you have mentioned will support and work pretty much in the same way, since its a well defined standard that they follow them strictly.
There exists many system calls that are specific to certain systems, if you use such system calls or API then you your code is at risk since there is a good chance that it may or may not be available on the other systems.
More on POSIX here.
To answer the first part, the answer is mixture of yes and no, the yes part, all distributions of Linux, their core, the kernel comes from the main repository tree.
The no part, is that there is huge differences between Kernel 2.x, Kernel 3.x, likewise, Kernel 4.x, so the underlying implementation of the API governing aspects of the system, such as device drivers, for example, is different. For example, kernel module that is dependent on Kernel v3.x implementation, will not work under Kernel v2.x.
That is nonetheless to say, differing implementations can be backported to the older versions of the Kernel.
However, the system calls are relatively static and have not changed much. (see SysCalls)
Distributions, on the other hand, encompasses the Kernel and all libraries, notably GNU C library, which would have been recompiled as updates are made where applicable.
Provided the API behind those runtime libraries have not changed, then code that targets a version of library can be recompiled against a newer version of them runtime libraries.
For security reasons, the kernel ceased to export characters necessary for writing security modules in the form of loadable kernel modules (Linux Kernel Module, LKM) starting with version 2.6.24.
And you can't export sys_call_table, again for security reasons.
But then, how can I filter filesystem requests?
I'll state it simply: I want to hook the "open" function!
I don't want to have to compile my own version of the kernel, what's the point of drivers? It should work for all kernels.
Please help, thought I would have more freedom than Windows with Linux, but now I see the most precious parts of my life are blocked in Linux.
I've written a kernel module that can do this called tpe-lkm. I've also mentioned it on some other questions similar to this here on StackOverflow:
access to the sys_call_table in kernel 2.6+
Reading kernel memory using a module
intercepting file system system calls
Hope one of these helps you out.
After a linux kernel upgrade, my VMWare server cannot start until using vmware-config.pl to do some re-config work (including build some kernel modules).
If I update my windows VMWare host with latest Windows Service Pack, I usually not need to do anything to run VMWare.
Why VMWare works differently between Linux and Windows? Does this re-compile action brings any benifits on Linux platform over Windows?
Go read The Linux Kernel Driver Interface.
This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still works just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.
It reflects the view of a large portion of Linux kernel developers:
the freedom to change in-kernel implementation details and APIs at any time allows them to develop much faster and better.
Without the promise of keeping in-kernel interfaces identical from release to release, there is no way for a binary kernel module like VMWare's to work reliably on multiple kernels.
As an example, if some structures change on a new kernel release (for better performance or more features or whatever other reason), a binary VMWare module may cause catastrophic damage using the old structure layout. Compiling the module again from source will capture the new structure layout, and thus stand a better chance of working -- though still not 100%, in case fields have been removed or renamed or given different purposes.
If a function changes its argument list, or is renamed or otherwise made no longer available, not even recompiling from the same source code will work. The module will have to adapt to the new kernel. Since everybody (should) have source and (can find somebody who) is able to modify it to fit. "Push work to the end-nodes" is a common idea in both networking and free software: since the resources [at the fringes]/[of the developers outside the Linux kernel] are larger than the limited resources [of the backbone]/[of the Linux developers], the trade-off to make the former do more of the work is accepted.
On the other hand, Microsoft has made the decision that they must preserve binary driver compatibility as much as possible -- they have no choice, as they are playing in a proprietary world. In a way, this makes it much easier for outside developers who no longer face a moving target, and for end-users who never have to change anything. On the downside, this forces Microsoft to maintain backwards-compatibility, which is (at best) time-consuming for Microsoft's developers and (at worst) is inefficient, causes bugs, and prevents forward progress.
Linux does not have a stable kernel ABI - things like the internal layout of datastructures, etc changes from version to version. VMWare needs to be rebuilt to use the ABI in the new kernel.
On the other hand, Windows has a very stable kernel ABI that does not change from service pack to service pack.
To add to bdonlan's answer, ABI compatibility is a mixed bag. On one hand, it allows you to distribute binary modules and drivers which will work with newer versions of the kernel. On the other hand, it forces kernel programmers to add a lot of glue code to retain backwards compatibility. Because Linux is open-source, and because kernel developers even whether they're even allowed, the ability to distribute binary modules isn't considered that important. On the upside, Linux kernel developers don't have to worry about ABI compatibility when altering datastructures to improve the kernel. In the long run, this results in cleaner kernel code.
It's a consequence of Linux and Windows being developed in different cultural environments and expectations: http://www.joelonsoftware.com/articles/Biculturalism.html. In short: Windows is designed to be suitable for users, whereas Linux evolves to be suitable for open source developers.
In my Operating Systems class we are looking to modify a Linux kernel with some simple system calls of our own in C.
What would be a good distro suited for this purpose? We don't need any frills, no GUI, a vanilla kernel, etc. The more basic the better.
I was able to modify the kernel pretty easily using a minimal Gentoo install.
Just install gentoo, follow the installation instructions, then:
$ emerge gentoo-sources
$ emerge emacs
$ cd /usr/src/linux
In my operating systems course last semester we used User Mode Linux, the big advantage being that when you hose the system, you can simply kill the process with no risk to the host environment.
Adding/Modifying system calls is tedious but trivial regardless of the kernel you use. However the 2.6 kernel is significantly more massive and complex, so if you're going to be modifying the code in a significant way the older kernels are easier to work with and much better documented. (ie: easier to find books and references)
Happy hacking :)
archlinux++
but really.. gentoo, slack, and arch are all more-or-less good choices
Arch Linux provides a great platform for kernel development that is also very functional. If you learn to use pacman, it will actually make testing your kernel modifications quite easily and provides the sources and tools in a sane manner.
I do think that if you are serious about learning linux and kernel hacking, doing a Linux From Scratch install should be on your list. It's a great distro/book and will let you build the platform for development yourself.
On all distributions, you can install the vanilla kernel.org sources instead of the distribution-related kernel packages, which is probably a good idea anyway when you want to do kernel development.
However, you'll be in trouble when you want to use any recent distribution with non-2.6 kernels, because they often build libc6 in a way that it cannot run with 2.4. Additionally, a lot of the guts of hardware management (like udev) require fairly recent kernels.
Apart from that, using Debian gives you a barebone system, and installing your own kernels is a breeze with kernel-package.
I wouldn't necessarily say any particular distro is geared towards kernel development as such, but if you want a traditional Linux distro that doesn't pile too much custom configuration stuff between you and the kernel, Slackware is a decent choice.
My suggestion is to grab the latest kernel. There will be more debugging features inside it than in an older kernel. Also, older kernels would pretty much look just as complex as the most recent to the newbie.
As for the distribution itself, you can't really go wrong. If all you want is to try some custom system calls, then grab whatever mainstream distribution which gives you a nice development environment. Then compile and try your customized glibc without installing it over the distro's.
When choosing a distro for kernel development, remember that it's the kernel you want to hack, not the distro itself. You will therefor want an easy distro that stays out of your way as much as possible. Ubuntu says out of the way fairly nicely.
IANAKH
A non-linux alternative is Geek OS, but this is very much aimed at the educational level, and is not a practical kernel. It is ultra-simple though.
well I have found one called "minix" it isn't really a linux distro, but it was made specifically for teaching, but if you can only use a linux distro, then it shouldn't matter, I am pretty sure all distros have the same kernel
Gentoo if you dont mind automated compilation (most people think that gentoo is Linux From Scratch => you have to do everything on your own).
Arch if you have slower computer (laptop).
Biggest advantage of these two is that they have very very good documentation and only installing Gentoo f.e. gives you basic knowledge about init system and what services has to run. If one copy&paste commands from guide it's worthless though (luckily handbook makes people think a bit, thus preventing kids from installing gentoo and taking over our neat #irc) :D