Florian, Thank for your explanations. We both agreed that for fast devel cycles we should use "make drivers/s390/net/testvm.o" from "/usr/src/linux-2.4".
I do agree with you on the recompilation of the module for any new future kernels. At this point I will be happy If I can compile my file on the kernel (2.4.9-31) that I am working on. What can or should I do for the scaled down testvm.c in order to compile it successfully by using "make drivers/s390/net/testvm.o" format? My system's /boot/kernel.h is: /* This file is automatically generated at boot time. */ #ifndef __BOOT_KERNEL_H_ #define __BOOT_KERNEL_H_ /* Kernel type s390 */ /* S/390 is always SMP: */ #ifndef __BOOT_KERNEL_SMP #define __BOOT_KERNEL_SMP 1 #endif #ifndef __MODULE_KERNEL_s390 #define __MODULE_KERNEL_s390 1 #endif #ifndef __BOOT_KERNEL_TAPE #define __BOOT_KERNEL_TAPE 0 #endif #ifndef __BOOT_KERNEL_VM #define __BOOT_KERNEL_VM 1 #endif #endif Thanks, Chong Tung-Sing Chong Software Engineer VM development, IBM S/390 Software Endicott, NY T/l : 852-5342 Outside Phone: 607-752-5342 E-mail: [EMAIL PROTECTED] Florian La Roche <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 04/17/2002 11:41:00 AM Please respond to Linux on 390 Port <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: compile error with 31-bit RedHat 7.2 On Wed, Apr 17, 2002 at 09:40:07AM -0400, Tung-Sing Chong wrote: > Florian, > > Are you saying we should not use the make to compile a file from > "/usr/src/linux-2.4" tree? For fast development, I should be able to use > the "make drivers/s390/net/testvm.o" from "/usr/src/linux-2.4". To use This should be done for fast devel cycles. > make modules or recompile the whole kernel just to make a module is taking > too much time. For example, I should not have to recompile the whole kernel > in RedHat distribution to just make a new netiucv.o module, right? I recommend doing this to get things right if you want to provide this modul for all available Red Hat Linux kernels and (might) also have to recompile the module for each new kernel we release from Red Hat. > > The scale down testvm.c has the #include instatement (#include > <linux/skbuff.h>) that causes the error. If you compile (make > drivers/s390/net/testvm.o") the scaled down testvm.c from > "/usr/src/linux2.4" in a 31-bit RedHat 7.2 system, you should see the same > error message. > > What is in the 31-bit RedHat 7.2 distribution that is preventing me to do > "make drivers/s390/net/testvm.o" from "/usr/src/linux-2.4"?. I just > compiled my file in TurboLinux 6.5.1 (2.2.19) also and I did not get any > error. So far RedHat distribution is the only distribution that I am not > able to do the "make drivers/s390/net/testvm.o". Has todo with /boot/kernel.h pointing at a currently running kernel and some include file trickery, but these things are not enough to get modules compiled for several different kernel versions. cu, Florian La Roche > > Thanks, > > Chong > > Tung-Sing Chong > Software Engineer > VM development, IBM S/390 Software > Endicott, NY > T/l : 852-5342 Outside Phone: 607-752-5342 > E-mail: [EMAIL PROTECTED] > > > Florian La Roche <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 04/17/2002 04:03:46 > AM > > Please respond to Linux on 390 Port <[EMAIL PROTECTED]> > > Sent by: Linux on 390 Port <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: compile error with 31-bit RedHat 7.2 > > > > On Tue, Apr 16, 2002 at 01:43:48PM -0400, Tung-Sing Chong wrote: > > Florian, > > > > Thanks for your respond. "add this as a patch to the kernel src.rpm and > > then rebuild the ...."--> Do you mean rebuilding the kernel with 2.4.9-31 > > source tree and compile my file again? Anyway I did the following ways > and > > got the same error: > > > > 1 - applied "kernel-2.4.9-31.s390.rpm", "modutils-2.4.13-0.7.1.s390.rpm", > > "kernel-source-2.4.9-31.s390.rpm" and "kernel-headers-2.4.9-31.s390.rpm". > > IPLed the system with shipped 2.4.9-31 kernel and compiled the > > testvm.c from /usr/src/linux2.4.9-31 tree. > > > > 2 - Rebuilt the kernel with the 2.4.9.-31 updates. IPLed the system with > > the rebuilt kernel and compiled the testvm.c from /usr/src/linux2.4.9-31 > > tree. > > > > However when I changed the Makefile in the directory > > "/usr/src/linux2.4/drivers/s390/net" to include the testvm.o and did the > > "make modules", the testvm.c was complied with only warning (no > undeclared > > error). I did this on both 2.4.9-17 and 2.4.9-31 kernel and trees. And I > > was also able to insmod the testvm.o with no error. > > > This is a good possibility to compile a module matching one kernel. Though > there is no guarantee that one module can be used for the 4 different > kernel > versions that we ship with Red Hat Linux. > > Your above method works fine for a fast development cycle, but if you want > to distribute the modules to other people, you should compile the module > against all four kernel versions we ship and that can be most easily be > done by using the source rpm, adding this new module and recompiling the > whole kernel. > > cu, > > Florian La Roche > > > > (I do not have to do this on SuSE SLES-7.0). > > > > The changed (in bold) /usr/src/linux2.4/drivers/s390/net/Makefile: > > ---------------------------------------------- > > # > > # S/390 network devices > > # > > > > O_TARGET := s390-net.o > > > > list-multi := ctc.o > > export-objs := iucv.o fsm-s390.o > > > > ctc-objs := ctcmain.o ctctty.o testvm.o > > > > obj-y += iucv.o fsm-s390.o > > obj-$(CONFIG_CTC) += ctc.o > > obj-$(CONFIG_IUCV) += netiucv.o > > > > include $(TOPDIR)/Rules.make > > > > ctc.o: $(ctc-objs) > > $(LD) -r -o $@ $(ctc-objs) > > > > > > My scaled down (only have #includes and #defines) "testvm.c": > > > Too bad, I thought I could see the whole source. :-) :-) > > > > -------------------------------------------- > > /*********************************************************************/ > > /*********************************************************************/ > > > > /* Debug defines */ > > /* #define DEBUG 1 */ > > /* #define DEBUG_MORE */ > > > > #define MODULE > > > > /* includes */ > > #include <linux/module.h> > > #include <linux/autoconf.h> > > #if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS) > > # define MODVERSIONS > > #endif > > #ifdef MODVERSIONS > > # include <linux/modversions.h> > > #endif > > #include <linux/kernel.h> > > #include <linux/config.h> > > #include <linux/errno.h> > > #include <linux/socket.h> > > #include <linux/sched.h> > > #include <linux/time.h> > > #include <linux/string.h> > > #include <linux/net.h> > > #include <linux/mm.h> > > #include <linux/interrupt.h> > > #include <linux/proc_fs.h> > > #include <linux/init.h> > > #include <linux/poll.h> > > #include <linux/inet.h> > > #include <linux/skbuff.h> > > #include <linux/unistd.h> > > #include <linux/if_arp.h> > > #include <linux/route.h> > > #include <net/protocol.h> > > #include <net/sock.h> > > #include <net/inet_common.h> > > #include <asm/io.h> > > #include <asm/system.h> > > #include <asm/ebcdic.h> > > #include <linux/version.h> > > > > We are currently working on porting an application on to 2.4 kernel. > > We did that for SuSE-SLES 7.0 (2.4.7) and now we like to work on the > Redhat distribution. > > Any help will be greatly appreciated. Thanks, > > > > Chong > > > > > > Tung-Sing Chong > > Software Engineer > > VM development, IBM S/390 Software > > Endicott, NY > > T/l : 852-5342 Outside Phone: 607-752-5342 > > E-mail: [EMAIL PROTECTED] > >
