How to test a syscall prior to compiling the kernel

How to test a syscall prior to compiling the kernel

[Dipanjan Das]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140604/7ab7f98b/attachment.html 

How to test a syscall prior to compiling the kernel

[Greg KH]

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

How to test a syscall prior to compiling the kernel

[Dipanjan Das]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140604/4eb15fe7/attachment.html 

How to test a syscall prior to compiling the kernel

[Augusto Mecking Caringi]

On Wed, Jun 4, 2014 at 12:59 AM, Dipanjan Das <mail.dipanjan.das@gmail.com>
wrote:

> 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.
>

Hi Dipanjan,

    Try this from the toplevel kernel source directory:

    make SUBDIRS=/your/specific/directory

-- 
Augusto Mecking Caringi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140604/4d138984/attachment.html 

How to test a syscall prior to compiling the kernel

[Greg KH]

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

How to test a syscall prior to compiling the kernel

[navid Rahimi]

there is a video on youtube , its length is just ~14 min . search that
, look at that.
don't worry about wasting time . it add a simple syscall , and call it
from userspace code for testing, all in ~14 min .

google is your friend

best wishes,
-navid

On Wed, Jun 4, 2014 at 8:49 AM, Greg KH <greg@kroah.com> wrote:
> 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
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

How to test a syscall prior to compiling the kernel

[Andev]

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.

-- 
Andev

How to test a syscall prior to compiling the kernel

[Valdis.Kletnieks at vt.edu]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140604/26ae0c56/attachment.bin 

How to test a syscall prior to compiling the kernel

[Andev]

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.

--

How to test a syscall prior to compiling the kernel

[Greg KH]

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 :)

How to test a syscall prior to compiling the kernel

[Andev]

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.

For a defconfig this is the time I get:

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

I have 4 gigs RAM and as mentioned earlier I created a 2 gig tmpfs and
disabled swap. What am I missing?

$ df -Ph
tmpfs           2.0G  913M  1.1G  46% /home/andev/ramlinux

-- 
Andev

How to test a syscall prior to compiling the kernel

[Greg KH]

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