I want to do kernel module programming. But, all sources tell that linux distributions patch the original kernel and that module codes might not run on them. If this is true, what should i do.I tried making lfs using ubuntu but errors cropped up at almost every step. I saw somewhere that arch, gentoo, Ubuntu Server without any packages selected during the installation, slackware, susestudio etc. are vanilla distributions. So, can i use them for module programming?
Please suggest keeping in mind that i need a GUI in the distribution.
Can this be followed?
PS: I have a intel core i3 processor and will be running the distros on vmware workstation.
If you want to program kernel modules then it doesn't matter which distribution you choose. You will need to be able to recompile the kernel from source and install a new kernel yourself. Even just for a kernel module you'll want to be able to compile the latest kernel and develop against that, otherwise you won't be able to get the module accepted in to mainline.
An alternative if the module is not to be released is to develop against a particular kernel version. In this instance then the choice of distribution should be chosen based on the target for the module - not the development environment.
So pick a distribution based on what you like:
1) Desktops - (GNOME, KDE, other)
2) Ease of use - (Ubuntu, Fedora, etc vs Arch, Gentoo)
3) Cutting edge vs Stable (Arch, Fedora vs Ubuntu vs Debian, Red Hat, CentOS)
Then head off to kernelbewbies to learn a bit about getting started with kernel programming (where to get the source, how to compile it). Then read Greg Kroah-Hartman's excellent book on linux device drivers. The interfaces will have changed (it's written about version 2.6 of the kernel and version 3.6 is currently being worked on). It can be found online here
You'll also want to learn how to use git. And more importantly how to use git to generate a patch and email it without messing it up! I don't have a website for this but a bit of googling will help.
Related
I'm working on a side project which requires me to configure and compile a tiny Linux System based on Ubuntu.
The result should be a tiny OS with the following features:
A Bootloader
A Kernel
A Process
A Thread
Miscellaneous (if possible)
A File System
Virtual memory
A Console
I read lots of documents about it, one of them being: http://users.cecs.anu.edu.au/~okeefe/p2b/buildMin/buildMin.html#toc3
I deleted the file system, and recompiled the kernel using make xconfig. I tried to deactivate modules and configurations many times, but it's not working for me.
How can I configure the kernel for the OS with only the features I listed above? What options can I disable or enable while still having a working system?
Having the Kernel very small is not important for Ubuntu, so maybe choosing Ubuntu is part of your problem. I would use as starting point what OpenWRT does. They do a good work making the Kernel small and it is easy to get started. OpenWrt Buildroot – Usage
try Linux From Scratch. It is a step by step approach on building a minimal Linux system from which you can evolve later on. http://www.linuxfromscratch.org/.
Use Gentoo Linux distribution - it's great for practicing on creation of Linux systems. Gentoo has excellent setup documentation, for example about configuring the kernel.
And Gentoo is a little easier and faster to setup than Linux From Scratch (LFS). If you want to go deeper, then LFS may be a good learning step too.
I am new to linux programming & interested to tweak linux kernel(though I am not sure, what to tweak, I am planning to write drivers for particular device). To learn internal of kernel, I have started from historic kernel release (first release).
My problem is, how to test whatever changes I am doing for development, without disturbing my current os environment.(ubuntu 12, 64 bit). Is there any way like virtual box, sandbox?
Along with these, if anybody send some good approaches to learn these things, I would be really greatful.
Thank You.
If you're new to linux programming then you really don't want to be tweaking the kernel. You really want to be an advanced programmer capable of programming drivers and complex software first.
But yes there is, you can can create a virtual machine using openbox or vmware. If you're really keen on tweaking the kernel you probably want to first just try compiling and configuring the kernel and seeing if that works.
Also make sure you're well acquainted with how the kernel works and advanced OS designs in general.
Search in google fr "Kernel configuration" you u will get many links how to configure your own kernel.
And one more thing do not use a outdated version of kernel ,always use latest stable release , because a lot of code and API is changed in new versions and no book in market is updated so ,, u have to read from kernel documentation. Thats the best way to learn the most updated information about linux kernel
Yes, you can test your changes on any of the commonly available virtual machines (VMs); that way, whatever changes you make to the VM kernel won't affect native OS.
Personally, I prefer using CentOS 64 bit on VMWare Player. With this setup, I got away with minimal system maintenance while was able to focus on the actual job at hand. Once the VM is up & running, you can download and compile one of the latest stable releases from kernel.org. Instructions on compiling your downloaded version of kernel could be found here and here; however, this may require little tweaking based on your actual setup. Once the VM is running on your desired version of kernel, using a combination of cscope and ctags will help you immensely in kernel code browsing.
Finally, if you want to become a serious kernel programmer and write your own device drivers, you need to get familiar with it in the first place. Below are a few excellent references -
Linux Device Driver by Corbet, Rubini, Kroah-Hartman, 3rd edition
Linux Kernel Development by Robert Love, 3rd edition
Understanding the Linux Kernel by Bovet, Cesati
Linux kernel source (ideally placed into your /usr/src/$(DESIRED_KERNEL) path, symlinked to /usr/src/linux)
Going through these books is a tedious job and chances are that you may hit the roadblock from time to time. kernelnewbies mailing list and StackOverflow are some of the few reliable places where people would be happy to answer to your queries.
Good luck!
I spent the last three weeks researching about crossdevelopment under Mac OS X. I want to achieve two separate results, but I believe they can be reached through the same path.
I want to
set up distcc to help my old Gentoo laptop using the iMac I recently got at home (OS X 10.6, 64 bit native) which I also use for iOS development, so Xcode 4 tools are already there;
develop my pet project which is an elf kernel for x86, x86_64, and arm (and I'll stop here as it's OT).
So, after a lot of that thinking thing we all do in these cases, I came up the idea that to reach the first goal I need to set up an i686-pc-linux-gnu toolchain (or is it i686-unknown-linux-gnu?) with all the appropriate versions (eg gcc-4.4) and make it callable by distcc. It seems like a reasonable task, but unfortunately there seem to be clearer tools and instructions to build toolchains for obscure archs like sparc or mips, and not a single reasonably updated resource on how to go for x86 the best way. Therefore, first question: is there anybody that succesfully build such a toolchain and feels like sharing the pain? :)
Second goal. My current workbench is made of Gentoo on an i686 laptop (yes, the same as the first goal) with all the regular development stuff, and I use QEMU to test it (its gdb integration is awesome). What I'd really like to do is to keep using the laptop while travelling (I do a lot of commuting) and continue to work and test on the iMac when I'm home (git is awesome in this respect). Hence, second question: is there anybody that have done something like this and wants to share?
I'd really appreciate any input. Seriously.
EDIT I know about MacPorts, crosstool, and crosstool-ng. I tried installing i386-elf-binutils 2.18 from MacPorts just to discover I have 2.20 in my laptop. Also I couldn't get gcc44 to produce i686-pc-linux-gnu elf objects, and using i386-elf-gcc is not an option as I need 4.4 and the packaged one is 4.3.
This is no easy task, specially because you want to cross compile for so many different platforms.
The most used approach is to run a Virtual Machine with the desired OS (e.g. VirtualBox, Parallels, VMWare Fusion) and install your workbench tools to work from it. This is very often used because it's not complex to setup and it also make it easier to write, test and debug code for/from the target system.
Of course, if you search enough you'll find all sorts of hacks/tricks to setup a toolchain on Mac OS X and compile code for other architectures:
One of these uses Buildroot, but that means that there is no official support for Mac OS X.
Another one, also interesting, offers a .dmg package with the tools needed to compile for Linux on MacOS X.
You already mentioned Gentoo, so I think you should take a look at Gentoo Prefix. Gentoo Prefix lets you install a small Gentoo system in a user defined directory (= prefix). From there, you may start a shell which lets you use portage (= Gentoo's package system) which should enable you to install the necessary tools.
I do not know in what shape Prefix on OS X today is, but I was able to install it on a friend's MacBook a year or so ago. If you are interested, I can give further details about the installation process which can be a bit tricky.
in a short I'm gonna release an application written in OCaml and I was planning to distribute it by source code.
The problem is that the OCaml development system is not something light neither so common to have installed so I would like to release it also in a binary way for various operating systems.
Windows makes no problem since I can compile it through cygwin and distribute it with the required dlls
OS X is not a problem too since I can compile it and distribute it easily (no external dependencies from what I've tried)
When arriving to Linux problems arrive since I don't really know which is the best way to compile and distribute it. The program itself doesn't depend on anything (everything is statically linked) but how to cover many distributions?
I have an ubuntu server 10 virtualized with an amd64 architecture, I used this machine to test the program under Linux and everything works fine. Of course if I try to move the binary to a 32bit ubuntu it stops working and I haven't been able to try different distributions... are there tricks to manage this kind of issue? (that seems recurring)
for example:
can I compile both 32 bit and 64 from the same machine?
will a binary compiled under ubuntu run also on other distributions?
which "branches" should I consider when wanting to cover as many distros as possible?
You can generally produce 64 and 32 bit binaries on a 64 bit machine with relative ease - i.e. the distribution usually has the proper support in its compiler packages and you can actually test your build. Note that the OS needs to be 64 bit too, not just the CPU.
Static binaries generally run everywhere, provided adequate support from the kernel and CPU - keep an eye on your compiler options to ensure this. They are your best bet for compatibility. Shared libraries can be an issue. To deal with this, binaries linked with shared libraries can be bundled with those libraries and run with a loader script if necessary.
You should at least target Debian/Ubuntu with dpkg packages, Redhad/Fedora/Mandriva with RPM and SUSE/OpenSUSE with RPM again (I mention these two RPM cases separately because you might need to produce separate packages for these "families" of distributions). You should also provide a .tar.bz2 or a .run installer for the rest.
You can have a look at the options provided by e.g. Oracle for Java and VirtualBox to see how they provide their software.
You could look at building it in the openSUSE Build Service. Although run by openSUSE, this will build packages for:
openSUSE SUSE
Enterprise variants
Mandiva
Fedora
Red Hat Enterprise/CentOS
Debian
Ubuntu
The best solution is to release the source code under a free license. You can package it for a couple distributions yourself (e.g. Debian, Fedora), then cooperate with other people porting it to others. The maintainers will often do most of this work with only a few required upstream changes.
Yes you can compile for both 32 and 64 bits from the same machine :
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
Most likely a binary running on Ubuntu will run on other distributions, the only thing you need to worry about if it you are using shared libraries (especially if you use some GUI framework or things like that).
Not sure what you mean by branch, but if you are talking about distribution, I would use the most vanilla Ubuntu distribution...
I'd recommend you just package a 32 and 64-bit binary for .deb and RPM, that way you can hit most of the major distros (Debian, Fedora, openSUSE, Ubuntu).
Just give clear installation instructions regarding dependencies, command-line fu for other distros, etc. and you shouldn't have much a problem just distributing a source tarball.
I want to change linux distro my Development(Host) Machine which I use for embedded development.
I cross-compile applications for many different processors. It is required for me to download different different libraries to evaluate their functionality/Performance/Stability on different devices , as well as on PC.
So Is ubuntu 9.04 a good choice for me?
Thanks,
Sunny.
If you are using gcc or other source based compiler that runs on linux then I would say yes, you want a linux distro, and ubuntu is currently the most popular/best. I would try to avoid distro specific things, drive down the middle of the road and you should be able to use any distro equally well.
That will largely depend on your needs. For an embedded system, I'd go with any distribution that sports a very small footprint and supports the necessary hardware.
Depending on your hardware, Debian might work fine. You could create your image with debootstrap which allows for fairly small customized installs. It still includes apt and other things which might not be desirable, although that could be to your benefit if you need to push out updates.
If you did go with Debian, you could most likely do all your development on Ubuntu and then push to your embedded system.
i use ubuntu for my host system and a chrooted gentoo install for building apps for an embedded target. I found gentoo was a good choice as it is source distributed and easy to select what version of a particular library is installed.
One thing that is good to know is that ubuntu and derivatives uses dash and not bash as /bin/sh. This confuses crosstools and can give you severe headaches.