Dmitry,
You are right about this. I overlooked it.
It's up to the MAASK girls to include your patches. Once things
stabilize we can start planning inclusion into openMosix.
Moshe
On Thursday, Mar 27, 2003, at 05:13 America/New_York, Dmitry Katsubo
wrote:
>>> hpc/mkdefcalls.c is used to produce mosasm.H but in the cycle
>>> fetching
>>> the SYMBOL_NAME declaration is omitted to not increment the counter
>>> for
>>> commented lines... So it do not write entries for NR_syscolls
>>> SYMBOL_NAME but to fetch NR_syscolls lines!
>>> ...
>>> for(i = 0 ; i < NR_syscalls && fgets(line, 2048, entry) ; i++)
>>> if(!strncmp(line, "\t.long SYMBOL_NAME(", 19))
>>> {
>>> for(c = &line[19] ; *c && *c != ')' ; c++);
>>> *c = '\0';
>>> if(strcmp(&line[19], "sys_ni_syscall"))
>>> strcpy(sys_name[i], &line[19]);
>>> } else i--;
>>> ^^^^^^^^^
>
> No! Stop! This will cause an infinite loop!
> Rule #1: do not touch the for-loop variable (i in out case),
> if you are not sure.
>
> That loop in ok!!! Yes, the array sys_name will contain holes...
> but the code after will handle it correctly:
>
> ...
> for(i = 0 ; i < NR_syscalls ; i++)
> if(sys_name[i][0])
> {
> ...
>
> Anyway, this program does not cover my error, as it deals only with
> "sys_ni_syscall's".
> Moshe, that file is correct, abort patching... :))
>
> I've attached the openmosix-2.4.20-migshm.patch, the shared memory
> patch
> for 2.4.20 kernel. I have kicked out some stupid hunks like this one:
>
> if(i)
> - mach[n] = loadinfo[i].pe;
> - else
> + {
> + mach[n] = loadinfo[i].pe;
> + }
> + else
> {
>
> but I could have made a mistake, as every human being.
> So use this patch only for testing!!!
> The patch applies almost clean (except top Makefile :)
> after openMosix-2.4.20-2.gz patch from website (dated 29-Jan-2003),
> as well as on latest CVS snapshot (with some fuzz :)
> Try to fix the Makefile yourself, it's quite easy :)
>
> MAASK Group: Please, have a look at the hunk, dealing
> with that Makefile! I think it's better not to rewrite
> SUBDIRS each time, but use "SUBDIRS += " instead.
> Please, be more clean with patches... Try to follow
> the code formatting rather then reformatting the code :)
> The patch is then more readable, IMHO.
> It will be also great, if someone write a stess test
> for shm too! I have run several promgrams from
> migshm-1.0/programs, but the migshm-1.0/README is too
> complicated to understand, what is the execution sequence,
> and what are the programms' dependencies.
>
> Anyway, good job! Now I could hardly see any process, I can't migrate!
> Oracle, MySQL, Apache are ready to migrate. But it will take
> some time to recompile the kernel on the other nodes, so
> I haven't tested the migration yet due to the lack of time.
>
> Now some words about testing... Of course, migshm would not add the
> stability to your system. I have run a stress test (omtest) which
> has brought the migshm-node down :(. Other 3 nodes are running ok:
>
> term1:~ # uptime
> 2:07pm up 20 days, 21:27, 1 user, load average: 0.06, 0.03, 0.00
>
> I know, I'd better not mix migshm and non-migshm kernels :)
> As for the normal load everything seemed to function
> for the half day, except Oracle, which oopsed after 10 mins.
> I will continue testing at the weekend.
>
> Actually I've faced some problems (see my prev. postings)
> with remote_sys_xxx calls handling. They are generated automatically,
> so, here are the steps, how to remove them "manually".
>
> After you run "make clean menuconfig", force the compilation of a
> mosasm.H
> from entry.S within a command:
>
> /usr/src/linux-2.4.20-mosix # HOSTCC=cc CONFIG_MOSIX=1
> TOPDIR=/usr/src/linux-2.4.20-mosix make mosasm.H -C > ./arch/i386/kernel/
> make: Entering directory `/usr/src/linux-2.4.20-mosix/arch/i386/kernel'
> cc -D__KERNEL__ -I/usr/src/linux-2.4.20-mosix/include -o offset
> offset.c
> ./offset < entry.S > mosasm.H
> make: Leaving directory `/usr/src/linux-2.4.20-mosix/arch/i386/kernel'
>
> Now disable the dependancy on mosasm.H, commenting the 2 lines in
> ./arch/i386/kernel/Makefile
> as the patch shows:
>
> === cut ==
> --- Makefile.old 2003-03-26 16:55:53.000000000 +0200
> +++ Makefile 2003-03-26 16:55:23.000000000 +0200
> @@ -49,7 +49,7 @@
> offset: offset.c $(TOPDIR)/include/linux/config.h
> $(TOPDIR)/include/linux/types.h $(TOPDIR)/include/linux/sched.h
> $(TOPDIR)/include/linux/signal.h $(TOPDIR)/include/linux/sys.h
> $(TOPDIR)/include/linux/kernel.h
> $(HOSTCC) $(HOSTCFLAGS) -D__KERNEL__ -I$(TOPDIR)/include -o
> offset offset.c
>
> -./mosasm.H: offset entry.S
> - ./offset < entry.S > mosasm.H
> +#./mosasm.H: offset entry.S
> +# ./offset < entry.S > mosasm.H
>
> endif
> === cut ==
>
> Now correct the mosasm.H itself and remove the faulty syscalls
> remote_sys_printlogs and remote_sys_flush as patch shows:
>
> === cut ===
> --- mosasm.H.old 2003-03-26 18:05:52.000000000 +0200
> +++ mosasm.H 2003-03-26 18:06:12.000000000 +0200
> @@ -267,10 +267,6 @@
> .long SYMBOL_NAME(sys_ni_syscall)
> .long SYMBOL_NAME(sys_ni_syscall)
> .long SYMBOL_NAME(sys_ni_syscall)
> -#ifdef CONFIG_SHM
> - .long SYMBOL_NAME(remote_sys_printlogs)
> - .long SYMBOL_NAME(remote_sys_flush)
> -#endif /* CONFIG_SHM */
>
> .rept NR_syscalls-(.-remote_sys_call_table)/4
> .long SYMBOL_NAME(sys_ni_syscall)
> == cut ===
>
> Now, type "make dep bzImage" as usual.
>
> The kernel seems to _compile_ with the next .config:
>
> #
> # openMosix
> #
> CONFIG_MOSIX=y
> # CONFIG_MOSIX_TOPOLOGY is not set
> CONFIG_MOSIX_SECUREPORTS=y
> CONFIG_MOSIX_DISCLOSURE=1
> CONFIG_MOSIX_FS=y
> CONFIG_MOSIX_DFSA=y
> # CONFIG_MOSIX_PIPE_EXCEPTIONS is not set
> CONFIG_openMosix_NO_OOM=y
> CONFIG_SHM=y
> CONFIG_SHM_FLUSH=y
> CONFIG_SHM_DEBUG=y
>
> #
> # Processor type and features
> #
> CONFIG_MK7=y
> # CONFIG_SMP is not set
>
> Both gcc-2.93.3 and gcc-3.2 have been tested for compilation.
>
> Have nice kernel hacking!
>
> <openmosix-2.4.20-migshm.patch.bz2>
|