Hi Greg, You have misunderstood the question. That, too, because me being too brief. What I tried to mean is NOT to test the syscall after the modified kernel is compiled and booted. That's easy. To add the syscall to the kernel, one needs to drop a C code implementing the body of the call itself to some appropriate location of the kernel source tree. Isn't it so? I am doing that for the first time and want to be sure that the compilation, especially the includes work. Otherwise, the kernel compilation may throw an error midway, thereby wasting my time. On 4 June 2014 09:22, Greg KH <greg@kroah.com> wrote:

On Wed, Jun 04, 2014 at 08:52:31AM +0530, Dipanjan Das wrote:

...

Hi,

While adding a syscall, how do I test the syscall code itself? If I

simply try

...

to compile the C file individually, will the compiler be able find the includes?

Did you try: man 2 syscall

greg k-h

On Wed, Jun 04, 2014 at 09:29:39AM +0530, Dipanjan Das wrote:

Hi Greg,

You have misunderstood the question. That, too, because me being too brief.

What I tried to mean is NOT to test the syscall after the modified kernel is compiled and booted. That's easy.

To add the syscall to the kernel, one needs to drop a C code implementing the body of the call itself to some appropriate location of the kernel source tree. Isn't it so? I am doing that for the first time and want to be sure that the compilation, especially the includes work. Otherwise, the kernel compilation may throw an error midway, thereby wasting my time.

There are lots of example tutorials online for how to add a syscall to the kernel, have you tried them? It should not take long to rebuild the kernel if you add a single syscall. You can always just rebuild a single directory, or a single file, if you are worried about long build times to find syntax errors in your code. Try doing the build for one file first, as you do development, to not have to worry about build times. Or, build on a ram disk, that goes much faster :) Hope this helps, greg k-h

On Wed, 04 Jun 2014 11:51:25 -0400, Andev said:

On Wed, Jun 4, 2014 at 12:19 AM, Greg KH <greg@kroah.com> wrote:

...

have to worry about build times. Or, build on a ram disk, that goes much faster :)

I was actually trying to get this to work the other day. Are there any good pointers on how to setup a ram disk and host a linux git tree on it? My google-fu failed me this time.

The trick to remember is that you probably don't want to use the ramdisk as the permanent host, so... 1) Setup your git tree on permanent storage 2) Set up your ramdisk 3) cd /my/source/tree 4) tar -c --exclude=.git -f - . | (cd /mnt/ramdisk && tar -xvf -) then cd /mnt/ramdisk and start building. Remember if you make changes to copy them back to /my/source/tree :) (The --exclude=.git will avoid copying about 900M onto the ramdisk. Skip that if you need the git history on the ramdisk for doing a bisect or similar)

On Wed, Jun 04, 2014 at 02:33:41PM -0400, Andev wrote:

On Wed, Jun 4, 2014 at 1:56 PM, <Valdis.Kletnieks@vt.edu> wrote:

...

The trick to remember is that you probably don't want to use the ramdisk as the permanent host, so...

1) Setup your git tree on permanent storage 2) Set up your ramdisk 3) cd /my/source/tree 4) tar -c --exclude=.git -f - . | (cd /mnt/ramdisk && tar -xvf -)

then cd /mnt/ramdisk and start building. Remember if you make changes to copy them back to /my/source/tree :)

(The --exclude=.git will avoid copying about 900M onto the ramdisk. Skip that if you need the git history on the ramdisk for doing a bisect or similar)

Thanks Valdis for the instructions.

So I tried the following to mount a tmpfs

$ sudo mount -t tmpfs -o size=2000m tmpfs ./ramlinux/ $ tar -c --exclude=.git -f - . | (cd ~/ramlinux && tar -xvf -)

And it works fine. I am not sure if tmpfs has any advantages over ramdisk.

It's the same thing :)

On Wed, Jun 04, 2014 at 03:02:02PM -0400, Andev wrote:

On Wed, Jun 4, 2014 at 2:33 PM, Andev <debiandev@gmail.com> wrote:

...

On Wed, Jun 4, 2014 at 1:56 PM, <Valdis.Kletnieks@vt.edu> wrote:

...

The trick to remember is that you probably don't want to use the ramdisk as the permanent host, so...

1) Setup your git tree on permanent storage 2) Set up your ramdisk 3) cd /my/source/tree 4) tar -c --exclude=.git -f - . | (cd /mnt/ramdisk && tar -xvf -)

then cd /mnt/ramdisk and start building. Remember if you make changes to copy them back to /my/source/tree :)

(The --exclude=.git will avoid copying about 900M onto the ramdisk. Skip that if you need the git history on the ramdisk for doing a bisect or similar)

Thanks Valdis for the instructions.

So I tried the following to mount a tmpfs

$ sudo mount -t tmpfs -o size=2000m tmpfs ./ramlinux/ $ tar -c --exclude=.git -f - . | (cd ~/ramlinux && tar -xvf -)

And it works fine. I am not sure if tmpfs has any advantages over ramdisk.

So I might have jumped the bullet on saying that it works fine. I see no difference between the compilation speed on native disk vs tmpfs.

Then perhaps disk I/O is not your limiting factor, but compute power is.

For a defconfig this is the time I get:

real 6m35.407s user 10m3.734s sys 1m0.514s

I don't know your hardware setup, but that seems a bit slow, are you building with all processors "full"? You should always add -j NUMBER" to your kernel make command, where NUMBER is 2x the number of CPUs you have in the box. Good luck, greg k-h