How to add .o file in the Linux Kernel

Printable View

07-16-2012
geewhan

How to add .o file in the Linux Kernel

I would like to know how would you enable the Congestion Control Algorithm correctly (lets call it Tcp_quic or quic).

My code is almost exactly like the tcp_veno.c file. Just the algorithm in the tcp_veno_cong_avoid() function changed.
I would like to attached the code on here, but I got an upload error. I would post it as well, but it is pretty long.

I have successfully compile the Linux Kernel with the C file (in the directory linux-3.4-rc7\net\ipv4\tcp_quic.c)
I just need to enable it, so I can use my algorithm and add it to the Kernel.

I realize that in the Linux Kernel folder(kernel\linux-3.3.6\net\ipv4), where I added the tcp_quic.c file, does not have .mod.o or .o file. With means that the tcp_quic.c did not compile successfully, right? However why did the compile in the terminal compile successfully? I read on one forum that may be I need to change something in the MAKEFILE to have .o file, is this true? I am not sure how I would do this if it is so.

I know that most people said that you should not mess with the Kernel, but it is something I would like to try.

The code below is how I want to enable the Congestion Control Algorithm.

Code:

echo quic > /proc/sys/net/ipv4/tcp_congestion_control

Also this is how I compile the Linux Kernel:

Code:

make-kpkg clean fakeroot make-kpkg --initrd --append-to-version=-geekernel kernel_image kernel_headers (this takes about 2 hours to compile)
07-17-2012
geewhan

So far I have done that steps on editing the MAKEFILE and the Kconfig file. Where I see veno, I copy and paste another line(s) of code and replace it with the word "quic".
What I put in the MAKEFILE is

Code:

obj-$(CONFIG_TCP_CONG_QUIC) += tcp_quic.o

What I put in the Kconfig file is:
(there is a lot of editing in this one I wont list them because I basically search for "vegas/veno" to copy and paste a new one for "quic"

I did get an error when I try using the code you have recommended, but I got an Error

Code:

fakeroot CONFIG_TCP_CONG_QUIC=m make-kpkg --initrd --append-to-version=-geekernel kernel_image kernel_headers

This is the error

Quote:

/usr/bin/fakeroot: line 176: CONFIG_TCP_QUIC=m: command not found

Here is the code in the fakeroot file around line 176:

Code:

export FAKEROOT_FD_BASE if test -z "$*"; then FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" ${SHELL:-/bin/sh} RESULT=$? else (LINE 176) FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@" RESULT=$? fi exit $RESULT

Did I miss something when I edit in the MAKEFILE or Kconfig file?

Thanks
07-21-2012
geewhan

I am waiting for the person who has helped me, but he/she hasn't responded for awhile so may be someone knows this.
Someone mention me something about the .config file, is that referring to kconfig file?
I ask because I do not know what that person mean by that below.

Quote:

At the end of kernel configuration, "make (x|menu|whatever)config" generates a .config file which is built using all the Kconfig segments.

When that person mention this part:

Quote:

You can simply edit .config and add CONFIG_TCP_CONG_QUIC=m to it. Then reconfigure using "make oldconfig" and then build the kernel using your regular "make-kpkg ..." command.

Is that person talking about the kconfig file the lines around here

Code:

config DEFAULT_CUBIC bool "Cubic" if TCP_CONG_CUBIC=y config DEFAULT_HTCP bool "Htcp" if TCP_CONG_HTCP=y config DEFAULT_HYBLA bool "Hybla" if TCP_CONG_HYBLA=y config DEFAULT_VEGAS bool "Vegas" if TCP_CONG_VEGAS=y config DEFAULT_VENO bool "Veno" if TCP_CONG_VENO=y config DEFAULT_QUIC bool "Quic" if TCP_CONG_QUIC=m

Thanks
07-26-2012
ledow

This has little to do with C programming. This is the kernel build process.

And the person helping you couldn't have put it clearer. Running "make xconfig" or "make menuconfig" or whatever generates a file named ".config" inside the kernel source folder. That file is built from all the Kconfig segments. When you edit that file (".config", which is hidden by default because of the "." in the filename), and then do a normal "make", you can change what the kernel build actually builds (i.e. which modules it uses).

But, honestly, if you couldn't work out that much, I don't see you getting much further in kernel programming without a LOT of help, and there the kernel mailing lists and other support are more useful for you.
07-26-2012
memcpy

I don't think you're listening to what people are telling you in your other threads.

You were very insistent that you can find the TCP stack code and modify it. After you were told repeatedly that it's unlikely that you would be able to understand something that took decades of work and many people to develop, you obviously didn't listen and started another thread about the same thing. I guess you ignored the comment about mailing lists, because then you went on to start modifying stuff in the kernel code and asking why it wasn't working. Soon after, you started another thread (which is the same bull........ you started with), and now this.

I'll reiterate, in case you decide to actually read peoples' advice this time. Stop trying to modify the Linux kernel if you don't understand what it's doing. Stop trying to change the TCP stack because it won't help performance. Stop posting threads about it here because these types of questions are best suited for a mailing list about your specific OS.
07-27-2012
ledow

Quote:

Originally Posted by memcpy

Stop trying to modify the Linux kernel if you don't understand what it's doing. Stop trying to change the TCP stack because it won't help performance. Stop posting threads about it here because these types of questions are best suited for a mailing list about your specific OS.

Agreed. Ambition is nice. Messing with your TCP stack in kernel space when you can't even work out how the Makefile works, or what a ".config" file is - that's just stupidity. And from the impression I get, I severely doubt you will be able to do anything that will actually provide any measurable difference because you don't even seem to understand much of what the TCP stack is actually doing. Honestly, do you know what SYN-cookies are without Googling it? Do you know understand window-scaling, or exponential backoff, or Nagle's algorithm, or congestion control? At one point you mention a research partner - if this really is part of serious research, I struggle to believe you can't find out a couple of things like "how to compile a kernel", "how to edit a kernel build config", etc. on your own and within about 5-10 minutes each.

I refer the OP to my comment in his other thread (didn't realise it was the same person): http://cboard.cprogramming.com/linux...ml#post1107680

For what you're trying to do, all we hear in this forum is the equivalent of "Hey, I've heard you can make engines run faster using nitroglycerine. I've got a car, so I thought I'd do it." - that's not so bad until you then see your other threads like this which are the equivalent of "What's a car?", "What's an accelerator?", "What's nitroglycerine?", "I poured some nitro in the tank and it just want bang" and, now, "Okay, so how do I put this nitroglycerine into a piston?".

I've been programming for about 15 years, and managed Linux systems for most of that time (personal and professional). The few times I've ever needed to play with kernel source, I used high quality, highly tested, highly sanitised code that was developed out-of-tree by people who spend their life on such code and was merely marked as "test" code. I have had literally a handful of occasions where it was necessary to edit that code (usually to compensate for some mechanism like locking or hardware access that had changed between kernels, and I just updated the patch with some obvious - but still hacky - changes to "just make it work" quickly until a real patch came out). In terms of working out what file to edit, how to compile it, how to get a working module out of it, etc. it was literally ten minutes of research the first time. In terms of actually generating code that didn't crash-and-burn, lock-up or not work at all, it took hours for even the simplest of changes and there's no way I would ever pass my modified patches off as anything other than a quick hack.

Honestly, curiosity, learning and experimentation are great. But it's taken you two months to work out how to build a kernel with a single modified .c file - and in the process you didn't realise that you couldn't use floating point in kernel-space, didn't realise that the errors thrown by that WERE because you didn't have floating point functions available, didn't realise that a /proc virtual file you wanted to use didn't actually exists (and thus you were baffled that echo'ing it returned a filesystem error), and lots of other things that you obviously didn't even bother to Google to find out the reason behind, much less understand the reason by your own introspection.

This is a C forum. You have a kernel project. Although you seem to have a grasp of C (albeit lazy and incomplete in terms of real-world errors), you obviously have no grasp of Linux kernel coding at all. Maybe you should stop asking in a C forum and follow the advice given to you by countless people - go find a kernel programming mailing list, forum, or other source of support for your questions which almost exclusively pertain to Linux kernel programming specifically. Hell, even a TCP programming forum would probably be more relevant to your problems.

That said, if this is a research project of any note, I would have to say that it's an incredibly lazy and slow-progressing one where you want other people to notice, interpret and fix your own schoolboy errors.