* How to test a syscall prior to compiling the kernel @ 2014-06-04 3:22 Dipanjan Das 2014-06-04 3:52 ` Greg KH 0 siblings, 1 reply; 12+ messages in thread From: Dipanjan Das @ 2014-06-04 3:22 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 3:22 How to test a syscall prior to compiling the kernel Dipanjan Das @ 2014-06-04 3:52 ` Greg KH 2014-06-04 3:59 ` Dipanjan Das 0 siblings, 1 reply; 12+ messages in thread From: Greg KH @ 2014-06-04 3:52 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 3:52 ` Greg KH @ 2014-06-04 3:59 ` Dipanjan Das 2014-06-04 4:14 ` Augusto Mecking Caringi 2014-06-04 4:19 ` Greg KH 0 siblings, 2 replies; 12+ messages in thread From: Dipanjan Das @ 2014-06-04 3:59 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 3:59 ` Dipanjan Das @ 2014-06-04 4:14 ` Augusto Mecking Caringi 2014-06-04 4:19 ` Greg KH 1 sibling, 0 replies; 12+ messages in thread From: Augusto Mecking Caringi @ 2014-06-04 4:14 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 3:59 ` Dipanjan Das 2014-06-04 4:14 ` Augusto Mecking Caringi @ 2014-06-04 4:19 ` Greg KH [not found] ` <CAOUBrm3BQyVJys4++o6zPUVxp7+dDSvPiF9MFpOUzSLpyzhN7g@mail.gmail.com> 2014-06-04 15:51 ` Andev 1 sibling, 2 replies; 12+ messages in thread From: Greg KH @ 2014-06-04 4:19 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAOUBrm3BQyVJys4++o6zPUVxp7+dDSvPiF9MFpOUzSLpyzhN7g@mail.gmail.com>]
* How to test a syscall prior to compiling the kernel [not found] ` <CAOUBrm3BQyVJys4++o6zPUVxp7+dDSvPiF9MFpOUzSLpyzhN7g@mail.gmail.com> @ 2014-06-04 8:24 ` navid Rahimi 0 siblings, 0 replies; 12+ messages in thread From: navid Rahimi @ 2014-06-04 8:24 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 4:19 ` Greg KH [not found] ` <CAOUBrm3BQyVJys4++o6zPUVxp7+dDSvPiF9MFpOUzSLpyzhN7g@mail.gmail.com> @ 2014-06-04 15:51 ` Andev 2014-06-04 17:56 ` Valdis.Kletnieks at vt.edu 1 sibling, 1 reply; 12+ messages in thread From: Andev @ 2014-06-04 15:51 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 15:51 ` Andev @ 2014-06-04 17:56 ` Valdis.Kletnieks at vt.edu 2014-06-04 18:33 ` Andev 0 siblings, 1 reply; 12+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2014-06-04 17:56 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 17:56 ` Valdis.Kletnieks at vt.edu @ 2014-06-04 18:33 ` Andev 2014-06-04 18:42 ` Greg KH 2014-06-04 19:02 ` Andev 0 siblings, 2 replies; 12+ messages in thread From: Andev @ 2014-06-04 18:33 UTC (permalink / raw) To: kernelnewbies 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. -- ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 18:33 ` Andev @ 2014-06-04 18:42 ` Greg KH 2014-06-04 19:02 ` Andev 1 sibling, 0 replies; 12+ messages in thread From: Greg KH @ 2014-06-04 18:42 UTC (permalink / raw) To: kernelnewbies 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 :) ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 18:33 ` Andev 2014-06-04 18:42 ` Greg KH @ 2014-06-04 19:02 ` Andev 2014-06-04 22:14 ` Greg KH 1 sibling, 1 reply; 12+ messages in thread From: Andev @ 2014-06-04 19:02 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* How to test a syscall prior to compiling the kernel 2014-06-04 19:02 ` Andev @ 2014-06-04 22:14 ` Greg KH 0 siblings, 0 replies; 12+ messages in thread From: Greg KH @ 2014-06-04 22:14 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-04 22:14 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-04 3:22 How to test a syscall prior to compiling the kernel Dipanjan Das 2014-06-04 3:52 ` Greg KH 2014-06-04 3:59 ` Dipanjan Das 2014-06-04 4:14 ` Augusto Mecking Caringi 2014-06-04 4:19 ` Greg KH [not found] ` <CAOUBrm3BQyVJys4++o6zPUVxp7+dDSvPiF9MFpOUzSLpyzhN7g@mail.gmail.com> 2014-06-04 8:24 ` navid Rahimi 2014-06-04 15:51 ` Andev 2014-06-04 17:56 ` Valdis.Kletnieks at vt.edu 2014-06-04 18:33 ` Andev 2014-06-04 18:42 ` Greg KH 2014-06-04 19:02 ` Andev 2014-06-04 22:14 ` Greg KH
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.