• Defining and Initializing
• Passing through
• Addition and deletion of elements

The linked list API is located in include/linux/list.h and the basic MACROs and functions that you need to know about are:

• INIT_LIST_HEAD()

• list_add(), list_entry(), and list_del()

• list_for_each() and list_for_each_safe()

The first thing you should do when you want to use a linked list, is to declare and define your list node data type. In this case the node is different than any linked list node that you may know outside the kernel.

Therefore a double linked list node would seem like:

struct person {
	char name[64];
	// ..

	struct person *next;
        struct person *prev;
};

but in the kernel way would be as:

struct person {
	char *name;
	// ..

	struct list_head engineers;
        struct list_head managers;
        // we can have multiple lists!
};

How do we declare a linked list?

Simple:

struct person employees;

Pushing forward towards our objectives, examples of code are:

Initializing:

INIT_LIST_HEAD(&employees.engineers);

Element addition:

struct person *node = NULL;
node=(struct person *)vmalloc(sizeof(person));
if (!node){
   printk(KERN_INFO "mymodule:vmalloc: could not alocate memory");
   return -ENOMEM;
}
memset(node, 0, sizeof(person));
strcpy(node->name, person_name);

list_add(&(node->engineers),&(employees.engineers));

Passing through list and deleting an element:

    struct list_head *pos = NULL;
    struct list_head *q = NULL;
    struct person *node = NULL;
    list_for_each_safe(pos, q, &employees.engineers) {
            node=list_entry(pos, struct person, engineers);
            if (!strcmp(node->name, person_name)) {
                 list_del(pos);
                 vfree(node);
            }
    }

I hope I haven't forgotten, or misplaced anything during code translation.

• adding and removing a directory, or file under proc
• handling I/O  of proc files

Having the proc_demo.ko module inserted into kernel, it will create /proc/{demo, demo/file} under you are able to perform simple I/O like:

• echo "what ever you want" > /proc/demo/file
• cat /proc/demo/file

Its purpose is to demonstrate the minimal usage of kernel proc API.

You should read Basic proc file system kernel API page first.

proc_demo.c

#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include<linux/vmalloc.h>
#include <linux/string.h>
#include<linux/proc_fs.h>
#include <asm/uaccess.h>


MODULE_LICENSE("GPL");

static char *file_content=NULL;
static struct   proc_dir_entry *proc_dir=NULL;
static struct   proc_dir_entry *proc_file=NULL;

ssize_t file_write(struct file *filp, const char __user *buff,
		   unsigned long len, void *data);

int file_read(char *page, char **start, off_t off,
		int count, int *eof, void *data);

ssize_t file_write( struct file *filp, const char __user *buff,unsigned long len, void *data)
{
    if (len>PAGE_SIZE) {
	printk(KERN_INFO "proc_demo module: file_write function len > PAGE_SIZE\n");
	return -ENOSPC;
    }

    if (copy_from_user(&file_content[0], buff, len))
	return -EFAULT;

    file_content[len]='\x0';
    printk(KERN_INFO "proc_demo module: you've written: %s\n",file_content);
    return len;
}

int  file_read( char *page, char **start, off_t off,int count, int *eof, void *data)
{
    return sprintf(page,"The user entered:\n%s\n",file_content),
	    strlen(page);
}

static int proc_demo_init(void) {

	int  ret=0;
	// We're alloc'ing memory for the file content buffer
	file_content=(char *)vmalloc(PAGE_SIZE);
	if (!file_content){
	    printk(KERN_INFO "proc_demo module: vmalloc: could not alocate memory\n");
	    goto demo_out;
	}

	memset(file_content, 0, PAGE_SIZE);

        // Creating the proc 'demo' directory
	proc_dir=proc_mkdir("demo", NULL);
        if (!proc_dir) {
	    printk(KERN_INFO "proc_demo module: demo directory creation failed\n");
            ret=-EAGAIN;
            goto proc_mkdir_failure;
	}

	/* creating 'file' and setting the read&&write function
	   handlers */
	proc_file=create_proc_entry("file",0600, proc_dir);
        if (proc_file) {
	    proc_file->read_proc  = file_read;
	    proc_file->write_proc = file_write;
	    proc_file->owner      = THIS_MODULE;
	}
	else {
    	    printk(KERN_INFO "proc_demo module: create_proc_entry: file\n");
	    ret= -EAGAIN;
	    goto proc_file_failure;
	}

	printk(KERN_INFO "proc_demo module: succesfully loaded\n");
        return ret;
proc_file_failure:
	remove_proc_entry("demo", NULL);
proc_mkdir_failure:
	vfree(file_content);
demo_out:
	printk(KERN_INFO "proc_demo module: not loaded loaded\n");
	return ret;
}

static void proc_demo_exit(void) {

        remove_proc_entry("file",proc_dir);
	remove_proc_entry("demo", NULL);

	if (file_content)
	    vfree(file_content);

	printk(KERN_INFO "proc_demo module: unloaded.\n");
}

module_init(proc_demo_init);
module_exit(proc_demo_exit);

Regarding a Makefile you can find a good example here.

• Exporting kernel state to user-space. It's like a kernel's point of view about the system.
• Communicating particular configuration to the kernel on the fly.  It's an interface to kernel components through which a system operator can interactive modify system behavior.

Shell commands that are common used with proc are: cat, echo and less. Examples of its usage could be:

• See system devices:

  cat /proc/devices

• Enable IPv4 forwarding:

  echo 1 >/proc/sys/net/ipv4/ip_forward

Now having enough about what we should know about operating proc from user space it is the moment to see how things are really done into kernel space.

Two main files from kernel source tree that you should inspect to see some proc API functions are:

• fs/proc/generic.c
• include/linux/proc_fs.h

Doing some Linux Cross Reference code search about proc_mkdir , create_proc_entry, and remove_proc_entry you will find that the kernel API is simple and their function signatures are like this:

struct proc_dir_entry *proc_mkdir
                      (const char *name,
                       struct proc_dir_entry *parent)

struct proc_dir_entry *create_proc_entry
                      (const char *name, mode_t mode,
                        struct proc_dir_entry *parent)

void remove_proc_entry(const char *name,struct proc_dir_entry *parent)

At this point is intuitive how we can create, or destroy directories and files under proc file system, but how do we process their I/O? The answer is like this: "Using a proc read and a proc write function setup using the resulting struct proc_dir_entry* after we link in the desired file."

By a proc read function you should understand a function used by kernel to process data when a /proc file is read from user space; usually performed in the reader user process context; and by a proc write function a function that is used by the kernel to process data when someone writes in a proc file.

proc read and write functions have the prototype as follows:

    int func_read(char *buffer, char **start, off_t offset,
             *int count, int *peof, void *dat)

ssize_t func_write(struct file *filp, const char __user *buff,
                   unsigned long len, void *data)

Furthermore, you can find a good example at Basic proc file system module page.

So, LXR (formerly "the Linux Cross Referencer") and some of its forks may be your good friend.  One instance can be found here http://lxr.linux.no

Google'ing after Linux Cross Reference Source phrase you will find some good sites where the kernel sources are indexed.

Good examples could be:

• http://www.linux-m32r.org/lxr/http/source
• http://users.sosdg.org/~qiyong/lxr/source/
• http://fxr.watson.org

Ups, that last link is devilish!

Basic things that you could do with a cross reference repository:

• search for a variable, macro, function name etc and find the places in kernel where it's defined and used (Identifier search)
• search for a particular file name (file search)

and many more, depending of your current repository.

Some first loadable kernel module may seen trivial but it's worth seeing.

Furthermore it's considered obvious that you've already:

• Explored  the Linux 2.6 kernel source repository , unpacked the latest kernel source into /usr/src and linked its directory to /usr/src/linux
• Copied the /boot/config-`uname -r` into /usr/src/linux and the did a make oldconfig there

If you are using GNU Debian/Linux or maybe Ubuntu:

• Installed the kernel-package and maybe some other software packages.
• Changed directory into /usr/src/linux, compiled the kernel and packed it into a deb file with make-kpkg --initrd <whatever> command.
• Installed the compiled kernel with dpkg -i <its deb file> and already rebooted the machine.  (VMware virtual machine?)

Now you have the newest Linux kernel running into your testing environment and you're ready to attack your first lkm.

Following source code is quite trivial and could be considered a skeleton. Code is self explanatory.

first.c

#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Copyright Whoever (C) Whenever 2008");

static int first_init(void) {

        int ret;

        /*      Do whatever initializings here. If some fails
         * you should uninitialize everyting initialized till
         * failure in reverse order.
         *
         * You could achieve this with goto statements.
         */

        printk(KERN_INFO "first module: loaded\n");
        return 0;

first_module_err:
        printk(KERN_INFO "first module: not loaded\n");
        return ret;
}
static void first_exit(void) {
        printk(KERN_INFO "first module unloaded\n");
}

module_init(first_init);
module_exit(first_exit);

OK, now you have a valid source code of your first lkm and you wish to compile and load it! That's made simple if you like to automate you task using shell. Keep in mind that GNU make is your friend.

Following code is a valid makefile that could be used:

Makefile

obj-m = first.o

KERNELDIR=/usr/src/linux
CWD=$(shell pwd)

.PHONY:clean

default: clean
        make -C $(KERNELDIR) I=$(CWD) M=$(CWD);   \
        insmod first.ko

clean:
        @INSERTED=`lsmod | grep first`;            \
         if [ ! -z "$$INSERTED" ]; then            \
            rmmod first;                           \
         fi;                                       \
         find . -name '.[a-z A-Z]*' -o -name '*.o' \
             -o -name '*.ko' -o -name '*.mod.c'    \
             -o -name 'Module.*' -o -name 'modul*' \
             | xargs rm -rf

Having those two files: first.c and Makefile into a testing directory you can compile and load the module performing one single command: make. Makefile has an auxiliary target you can follow: clean, that will erase every temporary file and directories resulting from compilation process and will unload the module.

If you want to see module's messages you can perform a dmesg | tail on your shell.

Enjoy!

I think it's well-established that I'm good with computers. What I haven't mentioned is that I run Linux on my laptop (and my desktop if it was working).

For those of you that are what I like to call computer stupid, Linux is an operating system. Like Windows XP or OS X. The difference between Linux and the mentioned operating systems is that Linux is free and it's source code is freely available on the internet. Which is amazing. Here's the exact newsgroup post that gave birth to Linux.

Anyway, enough of my gooing over Linux. I've spent most of yesterday evening, night, and basically almost every waking hour today trying to compile a new kernel for my laptop, patched with advanced APCI support. But why would I do this?

Right now, I'm unable to suspend or hibernate my laptop. It's buggy at best and more than usual craps out on me.

For those of you that don't know what suspend or hibernate is (or the difference between the two) it's one of those cool things that ACPI does. A quick crash course in computer engineering and hardware. RAM (or also called memory) is volatile. Data is only kept in the RAM as long as there is an electrical current going through it. This is why people back in the day lost Word documents if their computer shuts down in the middle of typing something up. Now most word processing programs will auto-save documents to the hard drive every 10 - 15 minutes by default, but this number can be changed, but I digress.

Suspend puts your computer in a sort of a low-level power mode, where there's just a small electrical current going through your computer. Just small enough so data stays in the RAM.

Now hibernate is completely different. Instead of keeping everything in the RAM, a snapshot of everything running in the RAM is taken and stored to a file (or in my case, a single partition called a swap partition). When you turn your computer back on, the data stored on the hard drive is loaded back into the RAM.

All of this usually works out of the box on Windows and Mac's. On Linux, it depends on the hardware and several other variables. In my case, I drew the short stick and it doesn't work out of the box. So I get to tinker.

Now, I'm a hardware guy. I'm not that much of a software guy. I can't code. So unfortunately for me, something like compiling a new kernel rarely works right the first time (man, I remember back in the day when I ran Gentoo before there was a GUI installer and everything had to be done via command line). So far, I've managed to completely crap out my video driver (fglrx), and my wireless NIC driver (new madwifi hal). After spending about an hour trying different things and screaming at my laptop, I finally fixed everything and started compiling again from scratch, a bit more familar with what to do now.

That's pretty much my rant for today. I'm waiting for this new kernel to compile (yet again), which takes about an hour or three, so I'm trying to keep myself entertained until it's done.

UPDATE (9/26): It's working. I have to shut down my X server and unload my video card driver to hibernate, otherwise it won't work and I have to force a shutdown.

Segments

Linux uses only 4 segments:

• 2 segments (code and data/stack) for KERNEL SPACE from [0xC000 0000] (3 GB) to [0xFFFF FFFF] (4 GB)
• 2 segments (code and data/stack) for USER SPACE from [0] (0 GB) to [0xBFFF FFFF] (3 GB)

                               __
   4 GB--->|                |    |
           |     Kernel     |    |  Kernel Space (Code + Data/Stack)
           |                |  __|
   3 GB--->|----------------|  __
           |                |    |
           |                |    |
   2 GB--->|                |    |
           |     Tasks      |    |  User Space (Code + Data/Stack)
           |                |    |
   1 GB--->|                |    |
           |                |    |
           |________________|  __|
 0x00000000
          Kernel/User Linear addresses

7.2 Specific i386 implementation

Again, Linux implements Pagination using 3 Levels of Paging, but in i386 architecture only 2 of them are really used:

   ------------------------------------------------------------------
   L    I    N    E    A    R         A    D    D    R    E    S    S
   ------------------------------------------------------------------
        \___/                 \___/                     \_____/ 

     PD offset              PF offset                 Frame offset
     [10 bits]              [10 bits]                 [12 bits]
          |                     |                          |
          |                     |     -----------          |
          |                     |     |  Value  |----------|---------
          |     |         |     |     |---------|   /|\    |        |
          |     |         |     |     |         |    |     |        |
          |     |         |     |     |         |    | Frame offset |
          |     |         |     |     |         |   \|/             |
          |     |         |     |     |---------|<------            |
          |     |         |     |     |         |      |            |
          |     |         |     |     |         |      | x 4096     |
          |     |         |  PF offset|_________|-------            |
          |     |         |       /|\ |         |                   |
      PD offset |_________|-----   |  |         |          _________|
            /|\ |         |    |   |  |         |          |
             |  |         |    |  \|/ |         |         \|/
 _____       |  |         |    ------>|_________|   PHYSICAL ADDRESS
|     |     \|/ |         |    x 4096 |         |
| CR3 |-------->|         |           |         |
|_____|         | ....... |           | ....... |
                |         |           |         |    

               Page Directory          Page File

                       Linux i386 Paging

7.3 Memory Mapping

Linux manages Access Control with Pagination only, so different Tasks will have the same segment addresses, but different CR3 (register used to store Directory Page Address), pointing to different Page Entries.

In User mode a task cannot overcome 3 GB limit (0 x C0 00 00 00), so only the first 768 page directory entries are meaningful (768*4MB = 3GB).

When a Task goes in Kernel Mode (by System call or by IRQ) the other 256 pages directory entries become important, and they point to the same page files as all other Tasks (which are the same as the Kernel).

Note that Kernel (and only kernel) Linear Space is equal to Kernel Physical Space, so:

            ________________ _____
           |Other KernelData|___  |  |                |
           |----------------|   | |__|                |
           |     Kernel     |\  |____|   Real Other   |
  3 GB --->|----------------| \      |   Kernel Data  |
           |                |\ \     |                |
           |              __|_\_\____|__   Real       |
           |      Tasks     |  \ \   |     Tasks      |
           |              __|___\_\__|__   Space      |
           |                |    \ \ |                |
           |                |     \ \|----------------|
           |                |      \ |Real KernelSpace|
           |________________|       \|________________|

           Logical Addresses          Physical Addresses

Linear Kernel Space corresponds to Physical Kernel Space translated 3 GB down (in fact page tables are something like { "00000000", "00000001" }, so they operate no virtualization, they only report physical addresses they take from linear ones).

Notice that you'll not have an "addresses conflict" between Kernel and User spaces because we can manage physical addresses with Page Tables.

Taken from http://tldp.org/HOWTO/KernelAnalysis-HOWTO-7.html

http://downloads.openwrt.org/whiterussian/0.9/

Use this URL:

http://downloads.openwrt.org/whiterussian/0.9/whiterussian-0.9.tar.bz2

unzip and move to the whiterussian-0.9/ folder. You should start by reading the README file or follow these instructions.

type the following command if you want to change setup options before compiling the distribution:

> make menuconfig

In my case, I didn't need to mess with that configuration. Probably you won't need.

> make

The way OpenWrt is created is as follows: All you download are configuration files. When you run the compilation scripts, they will download the source files from the Linux kernel and other programs needed, like the sources of the gcc compiler, the libraries for STD, and others. In the case of WhiteRussian, it downloads the sources for kernel version 2.4. Be aware that it will download the zip of the sources only if it's not found under the /dl folder of the root folder. So, the first time you compile it, it will download all the libraries and the kernel. The next time this won't happen, unless files are deleted from /dl folder.

-----

If you want to modify the sources, what I've done so far is modifying the Linux kernel. Because WhiteRussian downloads the kernel from a well known Linux kernel download website, it's necessary to tell the compilation scripts that I want it to download my modified version of the source files. In my case, I downloaded the source files for the kernel, applied a patch, zipped again, and uploaded it to my website. Then I found the configuration file I needed to modify, which is found here:

/whiterussian-0.9/toolchain/kernel-headers/

And opened the Makefile. There I found the variable LINUX_HEADERS_SITE, which was set to the Linux kernel download website, and changed it to the following:

LINUX_HEADERS_SITE=www.csee.usf.edu/~mjimeno \
http://www.fr.kernel.org/pub/linux/kernel/v2.4 \
http://www.kernel.org/pub/linux/kernel/v2.4 \
http://www.de.kernel.org/pub/linux/kernel/v2.4

I also modified the LINUX_KERNEL_MD5SUM, which of course changed when I compiled the sources again. (The md5sum the file comes with should be the one for the kernel files located in the Linux website, which of course doesn't change)

Then I ran "make clean" and "make" to see the changes.

...

Linus Benedict Torvalds was born in Helsinki, Finland, in 1969. A member of the minority Swedish-speaking population, he attended the University of Helsinki from 1988 to 1996, graduating with a Masters degree in Computer Science.

He started Linux not through a desire to give the world a first-class operating system but with other goals in mind. Its inspiration is in part due to Helsinki winters being so cold. Rather than leave his warm flat and trudge through the snow to the university’s campus in order to use its powerful minicomputer, he wanted to be able to connect to it from home! He also wanted to have a platform to use to experiment with the properties of the Intel 386, but that’s another story. Torvalds needed an operating system capable of such tasks.Linux was born.

It took Torvalds the better part of a year to come up with the very first version of Linux, during which he worked alone in a darkened room. In 1991, he announced his creation to the world, describing Linux as “just a hobby,” and saying it would never be big. It wouldn’t be until 1994 that it reached version 1.0. In the early days, Torvalds’s creation was fairly primitive. He was passionate that it should be free for everyone to use, and so he released it under a software license that said that no one could ever sell it.

However, he quickly changed his mind, adopting the GNU Public License. Torvalds was made wealthy by his creation, courtesy of the dot.com boom of the late 1990s, even though this was never his intention; he was driven by altruism. Nowadays, he lives in Portland, Oregon, with his wife and children, having moved to the United States from Finland in the late 1990s.
Initially, Torvalds worked for Transmeta, developing CPU architectures as well as overseeing kernel development, although this wasn’t part of his official work. He still programs the kernel, but currently he over-sees the Open Source Development Lab, an organization created to encourage open source adoption in industry and which is also referred to as the home of Linux.

I'm not sure I want to spew out a tutorial here; I am semi-retired from RTOS kernel writing for data acquisition, I know what an OS is.

The Google Chrome browser needs an OS. It needs the hardware initialized and it needs native file system services to place its persistent storage, whether as files or as objects in the Gears Database.

Chrome needs a graphics system to draw, and frame buffer primitives for it's rendering engine. It needs all the drivers to attach AV devices so you can VOIP. All browsers need this.

The newfangled and impressive WebTop, instant booting, ROM-based mini OS provides these minimal services, extracted from a full Linux, to allow web surfing and Skype without a boot from a full, disk-based OS. WebTop is an OS.

Now then, could a browser be an OS? Yes. As we see with the BEA Applications Server side of things, one may write a set of minimal services to take over after the BIOS, hand over to the Hypervisor, and provide a JVM with extended OS services. They are doing this now, you can buy a BEA Java Application server that does not require a server OS.

If the browser companies want to support the devices, to license drivers, or to use open source distros for the support of post BIOS housekeeping, then by all means, the browser could replace what we now know  as the Operating System.

One caveat - even the best Linux distributions, after all these years, and after great and astounding progress, still struggle with device support. Chew on that.

Related articles by Zemanta

• Stand-alone jemalloc for Linux
• ASUS bringing Splashtop instant-on OS to all its motherboards
• Red Hat unveils fully open-source hypervisor

#1: Installing from source when your system is primarily an .rpm or .deb system

Many new Linux users don’t understand that both rpm and apt (or dkpg) keep track of everything installed on the system. However, those systems (rpm, apt, and dkpg) can keep track only of packages they install. So when you find that obscure package that comes only in source and you compile it yourself, your package management system will not know what to do with it. Instead, create either an .rpm or .deb file from the source and install the package with the package management system so that system will be aware of everything you have installed.

#2: Neglecting the many graphical front-end package management applications

Most people don’t even realize that there are graphical front ends that take a lot of the guesswork out of installing packages in Linux. For yum (the command-line package management system for rpm), you can use Yumex for yum (installed with yum install yumex); you can use Synaptic or Adept for apt (installed with apt-get install synaptic or apt-get install adept).

#3: Forgetting to update the list of available packages

When using apt-get or yum, make sure you’re updating the list of available packages. Otherwise, your system will not remain updated with the latest releases of installed packages. To update with apt-get, you issue the command apt-get update. To update with yum, issue yum check-update.

#4: Not adding repositories for yum or apt-get

Both yum and apt-get use a listing of repositories that tell them where to locate available packages. But the default repositories (often called “repos”) do not include every Linux package known to Linuxkind. So if you run the command to install an application, and yum (or apt-get) can’t find the package, most likely you’ll have to add a repo to your sources listing. For yum, the sources are in /etc/yum.conf. For apt-get, they are placed in /etc/apt/sources.list. Once you have added a new repo, make sure you run the update so either apt or rpm is made aware of the new source.

5#: Not taking advantage of installing from a browser

Just as with Windows, when your system sees you are attempting to download an installable application, you’ll be asked whether you would like the package management system to attempt to install the file or just save it to disk. In both instances, you will be asked for the root password (so you must have access to said password for this to even work). One thing I’ve always like about this method (be it in a yum-based or dpkg-based system) is that it has almost always been good about locating and adding dependencies.

Naturally, this method works only when you are downloading a file that’s applicable to your system. If you attempt to download an rpm file on a Debian-based system, you won’t have the option of installing the file.

You can take this one step further and select the Always Do This… check box in the Firefox popup so that every time you download a file associated with your package management system, it will automatically prompt you for your root password and continue to install the package. This streamlines the process quite a bit.

#6: Forgetting the command line

Let’s say you’ve installed a headless server using Ubuntu or Debian (a common setup for Linux servers) and haven’t installed any of the graphical interfaces or desktops. To do any maintenance, you have to log in via ssh (because no admin would log in via telnet) and are limited to the command line only. Even so, your ability to keep your system updated or install new applications is not limited. You can still use yum or apt-get to manage your packages.

With a Debian-based system, you have another option: Aptitude. From the command line, issue the command aptitude and you will be greeted with a nice curses-based interface for apt. This system is easy to use and gives you an outstanding option for maintaining a gui-less server without losing functionality. Aptitude lists Security Updates, Upgradeable Packages, New Packages, Not Installed Packages, Obsolete Packages, Virtual Packages, and Tasks. As you scroll through the list, you will not only get the installed vs. the new package release numbers but also a description of the package. After using Aptitude, you will quickly see how simple updating Linux packages can be, even from the command line.

#7: Blindly unpacking tar files

I can’t tell you how many times I have downloaded a source package and without thinking, untarred the package not knowing its contents. Most times this works out fine. But there are a few times when the package creator/maintainer has failed to mention that the entire contents of the package are not housed in a parent directory. So instead of having a newly created directory housing the contents of the tar file (which can contain hundreds of files/directories), those files are blown up into the directory you unpacked them into.

To avoid this, I always create a temporary directory and move the tar file into it. Then, when I unpack the tar file, it doesn’t matter if the contents are contained within their own directory or not. Using this method will save you a LOT of cleanup in those cases where the creator didn’t pack everything in its own neat directory.

#8: Deleting those make files

When you’re installing from source, you’ll probably run make clean to get rid of all of those unneeded source files. But if you get rid of the Makefile, uninstalling will be a hassle. If you keep it, you can usually uninstall the program simply by issuing make uninstall from the directory housing the Makefile. A word of warning: Don’t dump all your Makefiles into one directory. First rename them so you know which application they belong to. When you want to uninstall the application, move the Makefile to another directory, rename it to its original name, and then run the uninstall command. Once you’ve uninstalled the application, you can delete the Makefile.

#9: Installing for the wrong architecture

You might notice that many rpm files will have an i386, i586, i686, PPC, 64, etc. There is a reason for this. Unless the rpm file has noarch included in the filename, that rpm file was created for a specific architecture. And when those files were created for that architecture, they were optimized for it, so they’ll will run better. Does that mean you can’t install an i586 on a standard 386 machine? Of course not. But it will not run as efficiently as it will on the indicated architecture. Now, you can’t install a PPC rpm on an x86 architecture. The PPC architecture is for the Motorola chipset. Nor can you install the 64 bit on a 32 bit. You can, however, install the 32 bit on a 64 bit (as in the case when you want to get Firefox running with Flash on a 64-bit machine).

#10: Failing to address problems with kernel updates

It used to be that updating kernels was a task left to the silverback geeks. No more. With the new package management systems, anyone can update a kernel. But there are some gotchas you should know about. One issue is that of space. With every update of a kernel, your old kernel is retained. If you continually update kernels, your system storage can quickly fill up. It’s always a good idea to check to see what older kernels you can get rid of. If you’re using rpm, issue the command rpm -qa | grep kernel to see what you have installed. You can remove all but the last two installed. It’s always best to keep two in case the one you are running gets fubar’d.

So guys who are using Ubuntu or any other distros please keep this things in mind while installing anything in your distros and you will never be in any problem.

Rootkit ها:

خیلی‌ها عقیده دارند که Rootkit ها مخصوص سیستم‌عامل لینوکس است. البته تا حدودی این حرف صحت ندارد. چون ویندوز هم Rootkit دارد اما صدایش را در نمی‌آورند! در یک بیان کلی بگویم که Rootkit ها دزد اطلاعات کاربران هستند، یعنی با ورود یک Rootkit به لینوکس شما، ممکن است اطلاعات مهم موجود در هارددیسک شما به سرقت برود. البته در 60 درصد مواقع Rootkit ها خود به خود ناپدید می‌شوند، زیرا لینوکس به این سادگی ها تسلیم نمی‌شود! این سیستم‌عامل به صورت موقت Port های باز را می‌بندد و Rootkit ، کامپیوتر شما را از دست می‌دهد. در این حالت (یعنی همان 60 درصد) هیچ اطلاعاتی از کامپیوتر شما به سرقت نمی‌رود.

Rooter ها:

روتر ها دسته‌ای از خطرناک‌ترین ویروس‌های لینوکس هستند که احتمال مبتلا شدن به آن‌ها بسیار کم است، اما با این وجود هرساله ده‌ها کامپیوتر که بیشتر آن‌ها " کارگزار " هستند به روتر ها مبتلا می‌شوند. کاری که روتر انجام می‌دهد این‌است که هسته‌ی لینوکس (که قابل ویرایش است) را به دل‌خواه خود تغییر می‌دهد و از طرف قربانی هرکاری که بخواهد در شبکه و اینترنت انجام می‌دهد که همه به پای قربانی نوشته می‌شود. این روتر ها معمولا در شبکه‌هایی که هکر ها با هم جلسه می‌گذارند در کمین می‌نشینند. مثلا یک روتر در جلسه‌ی مهمی که در irc.freenode برگذار شده پنهان می‌شود و به سیستم یکی از اعضا نفوذ می‌کند. البته در صورت تسلط کاربر به مفاهیم امنیتی، این روتر دست و پا بسته از سیستم قربانی خارج می‌شود. با این حال بیشتر سیستم‌های SERVER به این دسته از روتر ها مبتلا می‌شوند. البته بعضی از این‌ها در source های صفحات‌وب پنهان می‌شوند که این بیشتر در ویندوز رخ می‌دهد. زیرا فایرفاکس تسلیم این‌ها نمی‌شود!

squidanti ها:

squid نام نرم‌افزاری است که سیستم لینوکس شما را به proxy تغییر می‌دهد. در بیان ساده‌تر، لینوکس شما را به proxy متصل می‌کند. به تازگی برنامه‌های مخربی نوشته شده‌اند که به squidanti معروف‌اند. اگر شما از squid استفاده کنید و به برنامه‌ی مخرب ِ squidanti مبتلا شوید، هر بار که به اینترنت متصل می‌شوید (تقریبا همیشه) تعداد زیادی پیام تبلیغاتی در پنجره‌ی مرورگرتان مشاهده خواهید کرد. البته این پیام ها در فایرفاکس دیده نمی‌شوند اما در سایر مرورگرهای لینوکسی نمایان خواهند شد.

راه مبارزه=

به جز 3 ویروسی که در بالا ذکر شد، لینوکس دیگر ویروسی ندارد! البته آن 3 ویروس هم بسیار کم‌پیدا هستند! یعنی اگر شما مسلط باشید و راه‌کارهای مبارزه با آن‌ها را بدانید، به هیچ وجه آلوده نخواهید شد. یکی از این راه‌کارها استفاده از آنتی‌ویروس برای لینوکس است. البته بیشتر آنتی‌ویروس های لینوکس برای شناسایی ویروس های ویندوز ساخته شده‌اند، اما ضدویروس مخصوص لینوکس هم وجود دارد. (مثل:Linux Shield) یک راه‌ بهتر و اساسی‌تر استفاده از فایروال است. مثل برنامه Firestarter.

--

- ویروس کامپیوتری (فارسی - انگلیسی)

- هسته لینوکس

kernel nu didukung nyaeta versi 2.4 jeung 2.6, abdi mah ngango layer7 di kernel 2.6

Nu dibutuhkeun jang instalasina nyaeta:

1. Kernel linux tiasa download di www.kernel.org

2. Iptables download di www.nelfilter.org

3. layer7-filter download di http://sourceforge.net/project/showfiles.php?group_id=80085

4. Protokol nu dikenal ku layer7 download di http://sourceforge.net/project/showfiles.php?group_id=80085

keur nu ahli mah ceuk websitena teh : "Apply our kernel patch. Enable the new match option in Netfilter."

singkatna mah nambah modules anyar di kernel nyaeta layer7-filter.

1. download layer7-filter

2. buka kompresian file na

3. patch kernel source ku layer7-filter

#cd /usr/src/linux

#patch -p1 < ../tempat/patchkernel/file.patch <<< sesuaikeun jeung versi kernel

4. Pilih paket kernel supaya ngadukung layer7 nyaeta di bagian :

"Prompt for development and/or incomplete code/drivers" (under "Code maturity level options")
"Network packet filtering framework" (Networking → Networking support → Networking Options)
"Netfilter Xtables support" (on the same screen)
"Netfilter connection tracking support" (... → Network packet filtering framework → Core Netfilter Configuration), select "Layer 3 Independent Connection tracking"
"Connection tracking flow accounting" (on the same screen)
And finally, "Layer 7 match support"
Optional but highly recommended: Lots of other Netfilter options, notably "FTP support" and other matches. If you don't know what you're doing, go ahead and enable all of them.
5. Kompilasi jeung install kernel siga biasana, restart linux

6. Download, Install jeung patch iptables, piceun iptables bawaan na ngarah teu liuer, soalna abi can tiasa mun langsung pake iptables bawaan da teu aya source iptables bawaanna.

#cd /usr/src

#wget http://............iptables..tar.bz2

#tar jxf iptables..tar.bz2

#cd iptables

#patch -p1 < ../tempat/patchiptables/file.patch

#chmod +x extensions/.layer7-test

#make

#make install

7. Download protokol-protokol nu didukung ku layer7, install/copykeun

# wget http://l7-protocols-YYYY-MM-DD.tar.gz

#tar xzf l7-protocols-YYYY-MM-DD.tar.gz

#cd l7-protocols-YYYY-MM-DD

#make install

tah ayeuna linux na tos support layer7, mangga di cobian... heheheh...

salam

Linux Kernel Linked List Explained.

A very clever use of the offsetof() macro (which itself is very clever) is at the heart of this linked list implementation.

If you need support or help you will often be asked what version of Ubuntu you are running.

You could be asked what version of the Linux kernel you are running?

And what version of Gnome?

Do you know your network name?

How much memory is installed or what is the available disk space?

Here is a quick how to for finding out the basics:

System > Administration > System Monitor.

Click on the System tab.

Thanks to

Brass Cannon Consulting

The full story is here...

http://handsonhowto.com/older/ckernel.html

"Take a look in /usr/src -- you should see a symlink called "linux" which in turn points to a directory such as "linux-2.4.3". That would be excellent.

So, we want to remove the symbolic link /usr/src/linux (assuming it IS just a symbolic link!) and re-create it pointing to a new directory, "linux-2.2.20". Here's how to do that:

kevin@bazooka:/usr/src: su -
Password:
[root@bazooka /root]# cd /usr/src
[root@bazooka src]# ls -l
total 12
drwxr-xr-x    7 root     root         4096 Jan 31 08:03 RPM/
lrwxrwxrwx    1 root     root           12 Jan 31 08:30 linux -> linux-2.4.3/
drwxr-xr-x   17 root     root         4096 Jan 31 08:25 linux-2.4.3/

Note the "arrow" in linux -> linux-2.4.3/ and that the first character in the line is a lower-case l -- that's how you know that "linux" is a link, and not a real directory. You will only see that in a long directory listing, ls -l. If "linux" is a real directory and not a symlink, you'll want to rename it, not remove it. That would look something like this:

[root@bazooka src]# ls -l
total 0
drwxr-xr-x    7 root     root         4096 Jan 31 08:03 RPM/
drwxr-xr-x   17 root     root         4096 Jan 31 08:25 linux/
[root@bazooka src]# mv linux linux-2.4.3
[root@bazooka src]# ls -l
total 0
drwxr-xr-x    7 root     root         4096 Jan 31 08:03 RPM/
drwxr-xr-x   17 root     root         4096 Jan 31 08:25 linux-2.4.3/

Let's go back to the original example now, where we have an existing linux symlink pointing to a linux-2.4.3 directory. (Remember, we are about to compile an older stable kernel, version 2.2.20, to support a commercial module that we can't run under a 2.4 kernel.) Let's begin by removing the /usr/src/linux symlink.

[root@bazooka src]# pwd
/usr/src
[root@bazooka src]# ls -l
total 12
drwxr-xr-x    7 root     root         4096 Jan 31 08:03 RPM/
lrwxrwxrwx    1 root     root           12 Jan 31 08:30 linux -> linux-2.4.3/
drwxr-xr-x   17 root     root         4096 Jan 31 08:25 linux-2.4.3/
[root@bazooka src]# rm linux
rm: remove `linux'? y
[root@bazooka src]# mkdir linux-2.2.20
[root@bazooka src]# ln -s linux-2.2.20 linux
[root@bazooka src]# ls -l
total 12
drwxr-xr-x    7 root     root         4096 Jan 31 08:03 RPM/
lrwxrwxrwx    1 root     root           12 Feb  5 13:45 linux -> linux-2.2.20/
drwxr-xr-x    2 root     root         4096 Feb  5 13:44 linux-2.2.20/
drwxr-xr-x   17 root     root         4096 Jan 31 08:25 linux-2.4.3/

Why do we care about this "linux" symlink so much? The Linux kernel sources are picked up from a "linux" directory when they are packaged into a "tar" archive file; when you unpack them, therefore, they expect to go back into a "linux" directory. If you only have a single "linux" directory, and you unpack them into /usr/src without doing the steps above, they will overwrite some of your existing source files, and leave you with a real mess. You'll have old and new files all mixed together. In a situation like that, the only thing to do is remove the entire "linux" directory and start over. Using a symlink to point to the current version -- and keeping each version in its own directory -- makes it much easier to keep everything under control.

تقریبا تمام سیستم عامل ها کرنل دارند اما بعضی از آنها نسبت به سایرین برتری دارند. مثلا سیستم عامل لینوکس نسبت به ویندوز برتری نسبی دارد. از آن جهت که هسته لینوکس چند پارچه است، یعنی از لایه های مختلفی تشکیل شده و هر لایه یک وظیفه را دنبال میکند. پس در چنین شرایطی هیچ تداخلی در اعمال سیستم به وجود نمی آید و دسترسی نرم افزار ها به لایه های مختلف قطع میشود. اما ویندوز یکپارچه است و تمامی مراحل نام برده شده در یک لایه صورت میگیرد، به همین دلیل است که خطاها و اشکالات فنی در ویندوز خیلی زیاد بروز می یابند. برخی از کرنل ها کدباز (open source) هستند و از این جهت مشکلات کمتری دارند زیرا توسط عده ی زیادی از مردم در دنیا قابل توسعه و گسترش و رفع عیب است.

-  "کرنل" در ویکی‌پدیا: انگلیسی - فارسی

-  سایت رسمی هسته لینوکس

• Extent based file storage (2^64 max file size)
• Space efficient packing of small files
• Space efficient indexed directories
• Dynamic inode allocation
• Writable snapshots
• Subvolumes (separate internal filesystem roots)
• Object level mirroring and striping
• Checksums on data and metadata (multiple algorithms available)
• Strong integration with device mapper for multiple device support
• Online filesystem check
• Very fast offline filesystem check
• Efficient incremental backup and FS mirroring

After having decided to write NFS support for BtrFS today 24 hours ago,  I've come up with an initial version of the implementation. It works mostly, but its not perfect. I'm sure I have messed up some locking stuff. Let me see what the devs at btrfs devel have to say.

You can find the RFC patch here. I just hope it gets into BtrFS in a couple of iterations. :)

Image Courtesy : http://www.mobilelinuxinfo.com/category/openmoko/

QEMU

If you are running your OS in QEMU, then you are very lucky. If you have got the QEMU source code, just go and uncomment the lines starting with #define DEBUG_*. Now when you run QEMU, you will see tons of very valuable information being printed on the console. This makes QEMU a bit slow. But who cares for speed when debugging! The best thing about this approach is that the data printed by QEMU is in a user understandable format unlike the dump by usbmon which follows next.

USBMON

This method is a bit involved. First you have to mount the debugfs in /sys/kernel/debug. There you see a directory called usbmon. In there you see many files 1t,1u,2t,2u etc. The one prefixed with 'u' is supposed to be a newer version. The number identifies the bus number. The bus your device is connected to is obtained by running lsusb - an utility supplied under the usbutils package.

Once you've identified the bus your device is attached to, go ahead and do 'cat 3t' for example and you see tons of information of this form.

ffff810106c656c0 20722002 C Co:6:000:0 0 0
ffff8100aa4a0540 20735354 S Ci:6:003:0 s 80 06 0100 0000 0012 18 <
ffff8100aa4a0540 20741001 C Ci:6:003:0 0 18 = 12010002 00000008 6d0419c0 01430102 0001
ffff8100aa4a0540 20741011 S Ci:6:003:0 s 80 06 0200 0000 0009 9 <
ffff8100aa4a0540 20746000 C Ci:6:003:0 0 9 = 09022200 010100a0 32
ffff8100aa4a0540 20746008 S Ci:6:003:0 s 80 06 0200 0000 0022 34 <
ffff8100aa4a0540 20754001 C Ci:6:003:0 0 34 = 09022200 010100a0 32090400 00010301 02000921 11010001 22370007 05810305
ffff8100aa4a0540 20754012 S Ci:6:003:0 s 80 06 0300 0000 00ff 255 <
ffff8100aa4a0540 20759000 C Ci:6:003:0 0 4 = 04030904
ffff8100aa4a0540 20759006 S Ci:6:003:0 s 80 06 0302 0409 00ff 255 <
ffff8100aa4a0540 20768000 C Ci:6:003:0 0 36 = 24035500 53004200 20004f00 70007400 69006300 61006c00 20004d00 6f007500
ffff8100aa4a0540 20768006 S Ci:6:003:0 s 80 06 0301 0409 00ff 255 <
ffff8100aa4a0540 20775001 C Ci:6:003:0 0 18 = 12034c00 6f006700 69007400 65006300 6800
ffff8100aa4a0540 20775125 S Co:6:003:0 s 00 09 00

The format of this dump is pretty well documented in a in source text file located in Documentation/. You can also get it here. This output is really helpful.

This cool thing is used by device driver writers. The device for which they intend to write a device driver is  pass-through-ed to QEMU. They run a OS such as Windows in it and when the windows driver for the device interacts with its device, it can be snooped. And looking at this data, people write reverse engineered drivers!