Re: Kernel Compilation problem - Partially Solved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




You see, I  have Debian and I did read
/usr/src/doc/kernel-package/README.headers. I didnt understand it fully ,
but to the extent that kernel headers and user headers are separate and the
2 symlink solution is not good and is gonna go away and is not there is
Debian for sure.

Based on that , I undid the links from /usr/include to
/usr/src/linux/include that I had before. Also changed
#include<sys/time.h>  to linux/time.h in my function call defn, used the
flag -I/usr/src/linux/include (that had been metioned in the
/usr/src/doc/kernel-packages/README.headers) to compile the function call
file  and did bzImage and it worked. No more parse errors or anything .

THE NEW PROBLEM:
But my *user space* progran did not see the new call. Cos I have
#include<asm/unistd.h> there which does not have #define __NR_newcall in
it . And thats why I added the entry. And it worked.

This is the new problem: that the syscall added in the syscall table in
/usr/src/linux/include/asm is not seen by user program through
/usr/include/asm.

I thought it might be something with the way glibc works or something. But
I am gonna re-read the docs as you say cos I might have missed something
important.

Thanx all
 Narasimhamurthy Giri, Clemson
University Computer Science Dept.
-------------------------------------------------------------------------------
Judge not lest ye be judged yourself.
-------------------------------------------------------------------------------


On Fri, 15 Mar 2002, Seth Arnold wrote:

> On Fri, Mar 15, 2002 at 02:38:49PM -0500, Narasimhamurthy Giridhar wrote:
> > But I did get it working. I am just not sure if its the right way of doing
> > it. I changed /usr/include/asm/unistd.h by adding #define __NR_mycall 191
> > to it . I have made similar change in /usr/src/linux/include/asm/unistd.h
> > also.
> >
> > Is this good, safe etc. ???
>
> No. You are _still_ using /usr/include/asm/unistd.h. Kernel modules do
> not use /usr/include/. Never. (I'd be willing to argue that any modules
> that *are* using /usr/include/ are vastly broken, no matter if they work
> or not.)
>
> Yes, it is a pain in the arse to get these things setup. An important
> pain in the arse, so it is worth your time reading and re-reading all
> available documentation about this until you understand it. :)
>
> If you are on a debian system, apt-get install kernel-package, and go
> read /usr/share/doc/kernel-package/*eader* -- that is one of the most
> comprehensive documents I have seen on the matter. If you aren't on a
> debian system, it is worth your time to manually extract the file from
> whatever debian has easily available through their website. :)
>
> And, the kernelnewbies.org FAQ has this documented -- read, and re-read,
> until it makes sense. It will. It just takes time. :)
>
> Cheers :)
>
> --
> http://immunix.org/
>

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux